За да завършим изследването на базите данни и Web, ще прегледаме основните сървъри за приложения в Web (Web Application Server) с подходящите за тях Web сървъри и компоненти за бази данни.
Нека най-напред допълним фигурата, която започнахме в частта Web сървър:
Както става ясно от картинката, а и ще бъде изяснено по-подробно надолу, Web Application сървъра или Сървъра за приложения, е свързващото звено между Web сървъра и базите данни. Как става самата връзка между тези компоненти, ще разгледаме след като се запознаем с част от Web application сървърите в момента, индивидуално и в детайли.
Web Application сървърите обикновено се свързват с Web сървъра чрез неговия Приложен Програмен Интерфейс (Application Programing Interface - API) и играят ролята на разширение на Web сървъра, което може да обменя информация с базата данни чрез ODBC. Алтернатива на тези инструменти е приложение, разработено с използване на традиционни езици за програмиране (като C++, Python, Perl или Java), достъпът до което се осъществява чрез CGI (Common Gateway Interface). Други възможности за програмиране включват Java Server Pages (JSP) или други Web сървър-специфични разширения, подобни на Microsoft-ските Active Server Pages и на Natescape-ския server-side JavaScript за бази данни.
Понеже обекта на нашето изследване са не Web Application сървърите сами по себе си, а как те се използват за създаване на динамични страници и свързването на тези страници с бази данни, ще разгледаме и основните програмни езици за създаването на Web сайтове.
Това, което ще имаме предвид тук под динамична страница е страница, която е конкретно създадена от сървъра в отговор на клиентска заявка и която може да бъде различна всеки път в зависимост от разнообразни обстоятелства. Важното в случая, е че сървърът не просто чете обикновена HTML страница или текстов файл от диска и го изпраща към клиента - той трябва самостоятелно да извърши някаква работа за да създаде страницата. Интерфейсът, използван за тези динамични страници, ще ги наричаме приложения, се нарича CGI (Common Gateway Interface), и беше обект на разглеждане в предната глава. Първите приложения всъщност са компилирани програми, обикновено написани на С или C++. Но необходимостта да се програмира на С и да се прекомпилира изпълнимата програма всеки път, когато се налага да се направи малка промяна на създадените от нея текст или форматиране, ограничава използването на CGI и динамични страници. Затова беше разработен начин за създаване на страниците чрез скриптов език - Practical Extraction and Reporting Language (практичен език за извличане и отчети), или Perl. Той позволява на създателите на информация да пишат код на език, който до голяма степен прилича на опростена версия на С или C++. Той ще бъде разгледан по-подробно малко по-нататък.
Perl е популярен език в Web, особено в базирани на Unix или Linux системи, обаче ако сте Web разработчик, който няма предишни познания по С или C++ ще е много трудно да се го разучите. Вместо него се появяват нови скриптови езици, които улесняват създаването на страници. На системи, базирани на Unix и Linux и техните варианти, става популярен един нов език, наречен РНР (Personal Home Page. Съществуват и езици, насочени конкретно към определени типове потребители: например TCL е проектиран за по-лесно извършване на сложни математически изчисления в научна среда.
След създаването на SAPI, Microsoft и други независими разработчици произведоха приложения, които се свързват към Web сървъра чрез него. Това е начинът- чрез разработката на Microsoft - ISAPI, Active Server Pages, ASP да се свързват към IIS, както и на други техники на Microsoft за динамично свързване от сървърната страна. /Преди ASP най-често използваното средство беше Internet Database Connector (IDC). Той разкри един цял нов свят за Web разработчиците, използващи платформи на Microsoft, улеснявайки създаването на динамични страници, които използват база данни./ Това е една отворена среда за разработване на динамични и мощни Web-базирани приложения, в които се използват HTML, скриптови и ActiveX компоненти. Active Server Pages поддържа VBScripts и Jscript.
Вследствие успеха на ASP, Microsoft разработи Windows Scripting Host (WSH) - технологията, която дава възможност за изпълнение на скриптове в Windows 95, 98 и NT 4. WSH е независим от езика и поддържа JScript, VBScript и други езици. WSH дава възможност за изпълнение на скриптове от работното поле на Windows или от конзолен (MS-DOS) прозорец. WSH скриптовете са завършени сами по себе си и не е необходимо да бъдат вграждани в HTML документи. WSH е технология, впечатляваща с това, че разширява възможностите на JScript отвъд Web, като пренася езика в работното поле на Windows и операционната система. WSH скриптовете могат да се използват вместо MS-DOS скриптовете, като дават възможност за пълно използване на предимствата на Windows GUI, ActiveX и функциите на операционната система. /WSH може да бъде свален безплатно от Web сайта на Microsoft на адрес http://msdn.microsoft.com/scripting/
Както и при ASP, aналогичен е случая при Cold Fusion страниците на Allaire, които се свързват към Web сървъра си посредством стандартния сървърен API, но освен това поддържат и CGI интерфейса.
Netscape също създадоха графична среда за разработване и управляване на Web сайтове – LiveWire - за използване в своите сървъри. Една от възможностите на LiveWire е поддръжката на сървърни програми, написани на езика JavaScript.
Съществуват обаче и начини, за създаване на динамични странци за Web, които не се нуждаят от специфичен интерфейс за свързване към Web сървъра – такива са Java сървлетите. Те комуникират с Web сървъра без да използват специфичен за него API. Като се смесят обикновен статичен HTML с динамично генерирано съдържание от сървлети, се получават Java Server Pages, JSP.
Продължителят на ASP от страна на Microsoft се появи съвсем наскоро и беше наречен ASP+ или ASP.Net. Ако сравним ASP и ASP+, ще забележим че има два основни разлики във вторите сървърни страници: ASP+ поддържа кодовно написани и компилируеми езици като например Visual Basic, C++, Perl, и поддържа сървърни контроли, които могат да разделят кода от съдържанието, позволявайки по този начин добавяне в страниците. И въпреки че ASP+ не е обратно съвместима с ASP технологията, е възможно да се развива заедно с нея.
А сега нека разгледаме малко по-подробно някои от начините за създаване на динамични страници и свързването на тези страници с бази данни през Web, споменати по-горе.
UNIX е (в най-широк смисъл) операционна система, написана от програмисти, и за програмисти. Прелестта на UNIX за тези, които са отделили време да го научат е богатият набор от софтуерни средства, които той предлага. Perl е един от най-полезните от тези инструменти.
Perl всъщност е акроним, чиято най-възприета разширена версия е Practical Extraction and Report Language (практичен език за извличане и отчети). До голяма степен езикът е произлязъл от sed и awk — мощни UNIX инструменти за тези, които ги разбират, а за останалите - напълно непонятни командни програми.
Силата на sed и awk, както и на техния наследник Perl, почива основно върху вградените им възможности за обработване на текст чрез задаване на шаблони, търсене и заместване на фрази (или "низове") в цели групи от файлове, както и върху използването на неясните, но все пак изключително мощни, регулярни изрази на UNIX.
Perl стана популярен за работа в Web, тъй като в повечето свои въплъщения той е интерпретаторен език, подобно на първите версии на BASIC, а не компилаторен, каквито са С и C++. Основната разлика между компилирано и интерпретирано приложение е тази, че при компилирането цялата програма се транслира на машинния език на компютъра, на който ще се изпълнява, от друга програма, наречена компилатор. Компилираният файл се изпълнява самостоятелно. От друга страна, интерпретираната програма бива транслирана в процеса на изпълнението си от програма, наречена интерпретатор.
Тъй като съдържат инструкции на машинен език, компилираните програми обикновено се изпълняват по-бързо. Но поради същата тази причина те не са преносими от една компютърна платформа на друга. Компилираният за компютър на Sun или Macintosh код няма да може да се изпълни на Intel-базиран компютър, тъй като различните процесори, които задвижват тези машини, говорят напълно различни езици. Програмата ви трябва да бъде прекомпилирана за машината приемник, преди да заработи. Може дори да се наложи тя да бъде пренаписана.
За интерпретирания код на Perl няма такива ограничения. Всичко, от което се нуждаете, е някоя версия на интерпретатора на Perl (наречен Perl) на компютъра приемник. Има написани интерпретатори на Perl за всяка популярна компютърна платформа — Sun, Alpha, Apple, Intel и други. С много малко изключения, програмите на Perl се пренасят непроменени в която и да е среда.
Perl програмите не се компилират, поради което ги наричаме скриптове. Както скриптовете на шела в UNIX или файловете за пакетна обработка в MS-DOS и Windows NT, Perl програмите са просто текстови файлове, които се изпълняват посредством друга програма, която обработва техните команди.
“Perl скриптовете са просто текстови файлове, които можете да създавате чрез любимия си текстов редактор. В наши дни Perl е предпочитаният от Web разработчиците език, тъй като се използва лесно на UNIX машини. От неговата популярност, има и други изгоди: на първо място, огромното количество съществуващ код в мрежата.” (Perl, CGI and JavaScript, SYBEX) Много голяма част от него е безплатна, което означава, че можете просто да го поставите на Web сървъра си и да го изпълните независимо от това каква операционна система го задвижва. Голяма част от кода е написана, тествана и коригирана от UNIX програмисти, на които се е налагало да поддържат Web сайтове.
Следователно има смисъл да използвате Perl в Web сайта си, дори само от гледна точка на количеството усилия, което искате да вложите в написването на софтуер. Ако трябва да изпълните някаква задача и някой друг вече е написал кода за изпълнението й - и няма никакви възражения вие да го използвате - тогава защо да не се възползвате?
Колкото до начина по-който Perl се вписва в WWW – той е най-стария – CGI.
ASP е съкращение, означаващо Active Server Pages. Това е една отворена среда за разработване на динамични и мощни Web-базирани приложения, в които се използват HTML, scripts и ActiveX компоненти. Може би сте запознати с някой скриптов език (VBScript или JScript). За разлика от тях ASP е сървърско скриптoво обкръжение (server-side scripting environment). Нека поясним това по-подробно.
При обикновените скриптове програмата е част от страницата. Тя пътува от сървъра през Интернет до браузъра, който я изпълнява (интерпретира). По този начин потребителя получава изходния код на програмата.
При ASP нещата стоят по друг начин. Програмата е пак част от страницата, но се изпълнява на сървъра и до потребителя достига само крайният резултат. Това дава някои предимства, по-важните от които са:
<HTML>
<BODY>
<SCRIPT NAME="JScript">
for (i = 1; i <=10; i++){
document.writeln("Hello World!<BR>")
};
</SCRIPT>
</BODY>
</HTML>
<%@ LANGUAGE = "JScript" %>
<HTML>
<BODY>
<%
for (i = 1; i <=10; i++){
Response.Write("Hello World!<BR>");
};
%>
</BODY>
</HTML>
Както виждате, разликите са минимални. Вие правите обикновена HTML страница, като поставяте кода между <% %>. Това е указание за сървъра, че намиращото се между процентните скоби трябва да бъде изпълнено, и ако това парче код генерира някакъв текст, то той трябва да замести текста на програмата в резултатната страница. Накрая променяте разширението на файла на .asp.
Основното предимство на ASP обаче е неговата разширяемост. Написаната вече програма може да комуникира с определен клас ActiveX контроли, предварително инсталирани на сървъра. Такива ActiveX контроли могат лесно да бъдат създадени например чрез Delphi 5, като по този начин можете на практика да правите всичко. На всеки сървър има инсталирани няколко стандартни ActiveX контроли.
В ASP се използват пет стандартни обекта:
Обекта Request, се използва да получи информацията, която е пратена чрез HTTP заявка от потребителя.Oбекта Request поддържа:
Oбекта Response се използва за изпращането на информация до потребителя. Този обект поддържа само Cookies. Обекта поддържа и няколко properties и методи. Properties, които се поддържат са:
Методите, които се поддържат от обекта Response:
Обекта Server поддържа едно property-ScriptTimeout, което позволява да зададете стойност за това кога трябва да преключи изпълнението на скрипта. Oбекта поддържа и следните методи:
В обекта Session се съдържа информация за потребителите, които използват Web сървъра в даденият момент (сесия). Променливите на този обект съществуват, докато потребителят е в сесия. Обекта поддържа един метод-Abandon, който прекратява текущата сесия на Web сървъра, като унищожава всички обекти. Обекта поддържа и две пропъртита: SessionID, което съдържа идентификатора на текущата сесия; Timeout, което определя стойноста на приключване (time-out) за текущата сесия.
В обекта Application може да се съхранява информация, която остава по време на изпълнението на приложението. А това е цялото време, през което Internet Information Server-а работи. Това е добра възможност да се съхранява информация, която е за повече от един потребител, тъй като обекта се използва от всички потребители.
Една от гореспоменатите групи стандартни ActiveX контроли са ADO - ActiveX Database Objects. Те дават възможност за работа с различни платформи бази данни - най-вече MS Access и MS SQL Server. Kак точно става интеграцията на ADO в ASP беше описано подорбно в главата за бази данни и по-точно в частта, обясняваща базовата технология OLE DB.
ASP се стартира като процес на Web сървъра и е оптимизиран за използване от множество потребители. Ако изролзвате ASP, вие можете да разделите дизайна на вашата Web страница от детайлите на програмирането на компонентите и достъпа до бази от данни. Как работи всъщност Active Server Pages. Когато браузъра изисква даден ASP файл от вашият Web сървър, тогава Web сървъра извиква Active Server Pages, който прочита ASP файла и изпълнява всички команди, които се съдържат във файла, и връща като резултат HTML страница към браузара.
Не всички Web сървъри поддържат ASP. Това най-вече са MS IIS, Personal Web Server - PWS (този, който върви с Windows 98), както и някои други. Поддръжката на бази данни, както вече стана ясно, изисква и ODBC драйвер, но ако имате инсталиран някой от продуктите на MS Office вероятно необходимият драйвер е вече инсталиран.
Нека обобщим (Building a web based Data access and retreival Solution - Microsoft): ASP е просто казано стандартна HTML страница със скриптов код, вложен директно в документа. Един Web разработчик може да използва вложения код, за да имплементира бизнес логика заедно с HTML, или пък за да осигури достъп до логика, вложена във външни компоненти, или да се свърже директно към база данни. Когато един браузер се обърне към ASP, вложеният скрипт се изпълнява от скриптиращ двигател на сървъра и резултатите динамично се комбинират с HTML преди документа да се върне на браузера. Едно ASP приложение е сбор от ASP страници, заедно с включените HTML страници и компонентите, които приложението извиква.
Тази технология вече достигна версия 3.0 и за много хора стана основният начин за изграждане на динамични страници, цели сайтове и Web-базирани приложения на платформата на Windows сървър. Всъщност за Web програмистите работещи с операционни системи на Microsoft, ASP се превръща от вълнуваща нова технология в начин на живот.
За подробности по темата:
http://www.microsoft.com/msdn/
http://www.aspin.com
LiveWire e графична среда за разработване и управляване на Web сайтове. Netscape го създаде за използване в своите сървъри. Една от възможностите на LiveWire е поддръжката на сървърни програми, написани на езика JavaScript. Тези програми се използват по същия начин като CGI програмите, но са по-тясно интегрирани с Web сървърите и HTML страниците. LiveWire Database Service осигурява възможност за свързване на сървърните скриптове с бази данни. Сървърните скриптове осъществяват достъп до базите данни чрез стандартния за индустрията език SQL.
Сървърно-базираните JavaScript програми и HTML документите се компилират в платформено-независим байтов формат. Когато Web браузърът изиска компилиран документ, последният се превежда обратно в HTML формат и се изпраща на браузъра. Сървърно-базираните скриптове остават на сървъра и се зареждат, когато трябва да се изпълнява обработка от страна на сървъра. HTML документът, зареден от браузъра, комуникира със скриптовете, намиращи се на сървъра. По този начин се имплементират развити Web приложения, разпределени между браузъра, сървъра и други сървърни програми, като например бази данни или приложения за електронна търговия.
LiveWire предлага множество програмни обекти, които JavaScript може да използва за имплементиране на програми в CGI стил. Тези обекти опростяват комуникацията между браузърите, Web сървърите и скриптовете, изпълнявани от страната на сървъра.
Cold Fusion също е среда за създаване на Web приложения за хора, които искат да използват Web, за да разработват приложения от динамични страници и интерактивни Web сайтове на корпоративните интранет-и и в Интернет. Cold Fusion дава на разработчиците начин за бързо изграждане на мощни Web приложения, които се интегрират със сървърните технологии като релационни бази данни например. Cold Fusion е проектиран да посрещне особените нужди на разработчиците на Web приложения. Той предлага насочен директно към сървърната страна markup език, мощен сървър за приложения, и пълен набор от инструменти за създаване на Web приложения.
Едно Cold Fusion Web приложение започва с темплейти за създаване на динамична страница, вместо стандартните статични HTML документи. Темплейта е прост текстов файл, съдържащ и HTML, и Cold Fusion Markup Language (CFML). Вместо да се изпраща директно до браузера на потребителя, темплейтите се изпълняват от сървъра за приложения на Cold Fusion (Cold Fusion Аpplication Server), който генерира HTML страница, която едва след това се изпраща на браузера на потребителя. CFML е за Web сървъра, каквото е HTML за браузера. В днешно време приложенията с динамични страници се използват за широк кръг от компютърните нужди, включително електронна търговия, комуникация, сътрудничество, интерактивни Web сайтове и интранет системи.
Cold Fusion единствен прави проучване на разработването на Web приложения, което е следствие от разбирането на създателите му, че създаването на сложни Web приложения не трябва да изисква кой знае колко големи програмни умения. Вместо да изисква разработчиците да стават експерти в сложни програмни езици като Visual Basic, Java, или C++, Cold Fusion капсулира функционалността, осигурявана от тези езици в лесни за разбиране от сървърната страна тагове, които приличат на HTML таговете.
Cold Fusion се грижи за управлението от страна на клиента, сигурността, разгръщането на приложението, връзките с бази данни, и други задачи от по-ниско ниво. Улесняването на използването на програмните езици чрез таговете, не намалява силата и гъвкавостта му. Markup езика на Cold Fusion от сървърната страна, предлага цялата функционалност, от която може да се нуждаете за създаване на сложни и интелигентни приложения. За напреднали разработчици със собствени и специфични виждания, Cold Fusion осигурява отворен API за създаване на собствени тагове.
Cold Fusion е достъпен в две издания – корпоративно и професионално. Първото изисква Windows NT и Solaris, а второто – само Windows NT. Методите му за достъп до бази данни са стандартните – ODBC, OLE DB, Sybase и Oracle драйвери. Освен това има поддръжка за COM, CORBA и JavaBeans objects. Интерфейса към Web сървъра се осъществява посредством ISAPI, NSAPI, WSAPI, Apache Module, CGI, и е възможен за използване на различни Web сървъри - IIS, WebSite, Netscape, Apache.
Сървлетите са програми, които се изпълняват на Web сървър, действат като среден слой между една заявка, идваща от Web браузър или друг HTTP клиент, и бази данни или приложения на HTTP сървъра, и според някои автори (Marty Hall, 1999), “са отговора на Java технологията на CGI програмирането”. Какво всъщност правят сървлетите?
Най-напред те трябва да прочетат данните, изпратени от потребителя, които обикновено са въведени в някоя форма в web страница, но също могат да идват и от Java аплет или потребителски HTTP клиент. След като направят това, трябва да направят справка за друга информация за заявката, която е поставена в HTTP заявката/например подробности за възможностите на браузъра, бисквитки, хост име на заявяващия клиент и т.н./. Друга тяхна задача е генерирането на резултатите. Този процес може да изисква комуникация с база данни, изпълнение на RMI или СОRВА обръщение, изпълнение на налично приложение или директно изчисляване на отговора. След което получените резултати се форматират в документ, т.е. се поставят в HTML страница и се указва на браузъра какъв вид документ се връща (т.е. HTML), задаване на бисквитки и параметри за кеширане и други подобни задачи. Последната стъпка е изпращянето на документа обратно към клиента.
По принцип сървлетите не са ограничени само в Web сървъри или сървъри за приложения, които обработват HTTP заявки, те могат също така да се използват и за други видове сървъри. Например сървлетите могат да бъдат вграждани в пощенски или FTP сървъри, за да разширят тяхната функционалност.
Сървлетите имат разширена инфраструктура за автоматично парсване и декодиране на HTML данни от форми, четене и установяване на HTTP заглавни части, обработка на бисквитки, проследяване на сесии и много други подобни помощни средства от високо ниво. На това отгоре вие вече познавате програмния език Java и вече сте убедени, че Java технологията създава по-благонадежден и повторно използваем код отколкото C++. Защо да се връщате обратно към C++ за програмиране от страната на cървъра?
Сървлетите поддържат няколко възможности, които е трудно или невъзможно да се постигнат с обикновения CGI интерфейс. Те могат да комуникират директно с Web сървъра, докато обикновените CGI програми не могат, поне не без да използват специфичен за сървъра API интерфейс. Освен това множество сървлети могат да споделят общи данни, улеснявайки имплементирането на нулиране на връзки с бази данни и други подобни оптимизации, споделящи общи ресурси. Сървлетите могат също така да обработват информация от заявка за заявка, опростявайки такива техники, като проследяване на сесии и кеширане на предишни изчисления.
Сървлетите са написани на програмния език Java и следват стандартен API интерфейс. Следователно сървлети писани за, да кажем, I-Planet Enterprise Server могат да се изпълняват непроменени на Apache, Microsoft Internet Information Server (IIS), IBM WebSphere или StarNine WebStar. Всъщност сървлетите се поддържат директно или чрез plug-in модул на фактически всеки значителен Web сървър. Те вече са част от Java 2 Platform, Enterprise Edition, така че индустриалната поддръжка на сървлети става все по-широко разпространена.
Един от главните източници на уязвимост в традиционните CGI програми се дължи на факта, че те често се изпълняват в обвивки на общо-целеви операционни системи. И така CGI програмистът трябва много да внимава и да филтрира символи, като обратни кавички и двоеточия, тъй като те се обработват по специален начин от обвивката. Това е по-трудно, отколкото може да си помисли човек, и слабостите, произтичащи от този проблем, се откриват постоянно в широко използвани CGI библиотеки. Втори източник на проблеми е фактът, че някои CGI програми се обработват от езици, които не правят автоматична проверка за дължина на масиви или низове. Сървлетите не страдат от нито един от тези проблеми. Дори един сървлет да изпълни отдалечено системно обръщение за изпълнение на програма от локална операционна система, той не използва обвивката, за да направи това. А проверката за възможности за защита на паметта са централна част от програмния език Java.
Съществуват няколко безплатни или много евтини Web сървъри, които са добри за "персонално" използване или за не-обемни Web сайтове. Но има едно голямо изключение - Apache, който е безплатен, докато повечето комерсиални Web сървъри са сравнително скъпи. Така или иначе, след като вече имате Web сървър, добавянето на поддръжка на сървлети към него (ако не е предварително конфигуриран за поддръжка на такива) струва съвсем малко. Това е в контраст с много други CGI алтернативи, които изискват значителна първоначална инвестиция за закупуването на собствен пакет.
Java Server Pages, JSP технологията позволява смесването на обикновен статичен HTML с динамично генерирано съдържание от сървлети. Много Web страници, които са изградени от CGI програми, в основата си са статични и имат части, които се променят ограничено до няколко малки позиции. Но повечето CGI вариации, включително и сървлетите, ви карат да генерирате цялата страница чрез програмата, дори и ако в по-голямата си част тя е една и съща. JSP ви позволява да създадете две отделни части.
Съществуват много технологии за изграждане на web приложения, които да поддържат динамично съдържание /голяма част от тях са разгледани в тази дипломна работа/, но Java Server Pages (JSP) неслучайно привлече вниманието на програмното общество. JSP не само не се влияе от смяната на платформите и на Web сървърите, които я поддържат, но ефективно смесва силата на Java технологията от сървърната страна с WYSIWYG (what you see is what you get = каквото виждате е каквото получавате) технологията на статичните HTML страници. JSP страниците се състоят от: Статични HTML/XML компоненти, Специални JSP тагове, Скриплети (scriptlets), които всъщност представляват код, написан на програмния език Java
ASP е конкурентна технология от Microsoft. Преимуществата на JSP са двойно повече. Първо, динамичната част е написана на Java, a не на VBScript или друг ASP-специфичен език, което е по-мощно като концепция и по-добре съответства на сложни приложения, които изискват повторно използваеми компоненти. Второ, JSP е преносим на други операционни системи и Web сървъри, така че не сте ограничени само до Windows NT/2000 или IIS. Можете да използвате същия аргумент, когато сравнявате JSP c ColdFusion - при JSP можете да използвате Java и не сте обвързани с определен сървърен продукт.
РНР е безплатен, с отворен изходен код, вграден в HTML скриптов език, който е някак си сходен и с ASP, и с JSP. Предимството на JSP е, че динамичната част е написана на Java - език, с който може би вече сте запознати и който вече притежава разширен API интерфейс за мрежови достъп, достъп до бази данни, разпределени обекти и т.н., докато РНР изисква научаването на един изцяло нов език.
Важно е да се отбележи, че JSP спецификацията е стандартно разширение, дефинирано върху сървлетния API. Но между двете технологии има огромни различия. За разлика от сървлетите, които са програмна технология, изискваща значителен опит като разработчик, JSP претендира за много по-голяма аудитория. JSP могат да се използват не само от разработчиците, но и от проектантите на страници, които в този случай ще изиграят много по-централна роля в разработването на жизнения цикъл. Друго предимство на JSP е разделянето на статичното от динамичното съдържание. При сървлетите, логиката за генериране на динамично съдържание е съществена част от самия сървлет, и е стабилно свързан към статичното представяне н темплейти, отговорни за потребителския интерфейс. По този начин дори малки промени направени в потребителския интерфейс, ще рефлектират върху прекомпилирането на сървлета. При JSP логиката за генериране на динамично съдържание е запазена отделно от статичното представяне на темплейти, чрез капсулирането му във външни JavaBeans компоненти. Така, когато дизайнера на страницата направи някакви промени в темплейта за представяне, JSP страницата автоматично се прекомпилира и презарежда в Web сървъра чрез JSP двигател (engine). Друго предимство пред сървлетите е че веднъж написани, те “вървят” навсякъде. JSP страниците могат да бъдат местени лесно на различни платформи и web сървъри, без да се променят.
Динамичното съдържание може да бъде представено в различни формати. В JSP няма нищо, което да определя че данните в JSP страницата трябва да бъдат в точно определен формат.
В крайна сметка, JSP може да осигурява поддръжка на разнообразна клиентела – варираща от обикновените браузери, използващи HTML/XML, през мобилните телефони и PDA, използващи WML, до други приложения, използващи XML. Това предлага разширяване на границите за разработване на приложения, използвайки корпоративните Java API.
Изцяло се основава на сървлетните API. Ако можете да пишете сървлети, има много малко, което трябва да позабравите, за да започнете да създавата JSP. Всъщност разработчиците на сървлети са с огромно предимство, защото JSP не е нищо повече от сървлети от по-високо ниво на абстракция. Можете да правите всичко, което правите със сървлетите и с JSP, но във втория случай – много по-лесно.
SSI e широко поддържана технология за вмъкване на външно дефинирани части в статична Web страница. JSP е по-добра, тъй като имате по-богат набор от инструменти за изграждане на тази външна част и имате повече опции относно статуса на HTTP отговора, при който всъщност се вмъква динамичната част. Освен това SSI е реално предназначена само за елементарни вмъквания, не за "реални" програми, които използват форми от данни, правят връзки с бази данни и т.н.
JavaScript, който е напълно различен от програмния език Java, обикновено се използва за динамично генериране на HTML при клиента, изграждайки части от Web страницата, докато браузърът зарежда документа. Това е полезна възможност, но обработва само ситуации, при които динамичната информация се базира на обкръжението на клиента. С изключение на бисквитките, данните от HTTP заявката не са достъпни за Javascript подпрограми от страната на клиента. И тъй като в JavaScript липсват подпрограми за мрежово програмиране, JavaScript кодът при клиента няма достъп до ресурси от страна на сървъра, като бази данни, каталози, ценова информация и др. JavaScript може да бъде използван и на сървър, най-често на Netscape сървъри, и като скриптов език за IIS. Ho Java е далеч по-мощен, гъвкав, благонадежден и преносим.
Обикновеният HTML, разбира се, не може да съдържа динамична информация, така че статичните HTML страници не могат да бъдат базирани на потребителски вход или източници на данни от страна на сървъра. JSP е толкова лесен и удобен, че си струва с него да се подобрят HTML страниците, които иначе извличат доста малка полза от вмъкването на динамични данни. По-рано трудностите при използване на динамични данни изключваха възможността за тяхната употреба освен в много ценни отделни случаи.
За да завършим разглежданата тема и да дообогатим познанията в областта на web приложенията с бази от данни ще разгледаме два работещи примера на проекти, създадени за курса по Web-based Interface to Databases, воден от г-н Красен Стефанов.
Ще спрем вниманието си на най-често използваните напоследък технологии за създаване на web базирани приложения с бази от данни – ASP и JSP страници.
Проектът, от който са разгледаните по-долу части представлява Web презентация на електронен магазин за музикални дискове и можете да го видите тук. За да се придобие по-добро впечатление обаче, на фигурата по-долу е показана първата страница от него:
Направен е опит разгледания сайт да отговаря на основните изисквания за добре направен Web сайт а също и да включва основните действия, които се изпълняват в Базата данни – търсене, въвеждане и извеждане на информация.
Базата данни (ourdb.mdb) е реализирана на MSAccess 2000 и включва 5 таблици:
Album – съставена е от 8 колони:
Album_Songs – съставена е от 18 колони:
Artist – съставена е от 2 колони:
Log – съставена е от 2 колони:
Basket – съставена е от 2 колони:
Таблиците в базата данни са свързани, както на фигурата по-долу:
А сега нека малко по-подробно да поясним действията, които се извършват в едно asp приложение, за да се свърже то с базата данни и как се извлича информацията от съответната таблица в asp страницата. /Ще предполагаме че читателя има известни познания от VBScript, SQL и HTML/
<%
dim i
filePath = Server.MapPath("ourdb.mdb")
//на променливата filePath се присвоява относителния път за достъп до Microsoft
//Access базата данни - ourdb.mdb
strConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & filePath
//обявява се доставчика - Microsoft.Jet.OLEDB.4.0, базовата технология - OLE
//DB и пътя за достъп до базата данни - в променливата Data Source
Set cn = Server.CreateObject("ADODB.Connection")
//създава се връзка с базата данни чрез ADO обектите
cn.Open strConnectionString
//отваря се създадената с базата данни връзка
Album_Id = Request.QueryString("Album_Id")
//присвоява на променливата Album_ID резултата от изпълнението на предното
//ASP, следващ "Album_ID" текста
strSQL="SELECT Artist_Name, Album_Name, Genre, Price, Picture FROM Album WHERE
Album_Id="+Album_ID+""
//заявка, която селектира от базата данни информацията за албум - съответно:
//име на изпълнител, име на албум, жанр, цена, обложка от таблицата Album,
//където номера на албума е Album_ID
set RS = cn.Execute(strSQL)
// присвоява на променливата RS изпълнението от SQL заявката
strSongs="Select * FROM Album_Songs WHERE ID="+Album_ID+""
//заявка, която извлича от таблицата Album_Songs в базата данни, всички полета
//(в случая имената на песните) от албум с номер Album_ID
set RSongs = cn.Execute(strSongs)
//присвоява на променливата RSongs изпълнението на горната SQL заявка
%>
<html>
<head>
. . .
<table width=172 height=172 border=0 cellspacing=0 cellpadding=1>
<tr><td align=center bgcolor=#336699>
<img src="images/<%=RS("Picture")%>"" height=170 border="0"></td></tr>
//извежда се съответната на албума с номер Album_ID картинка от таблица
//Album на базата данни
<tr><td valign="top" class="pdesc">
<p>
<br><font color="#FFFF99">
<%
i=0
While i<17
i=i+1
if not IsNull(RSongs(i)) then
%>
<br>
<%
Response.Write(i &" " & RSongs(i))
end if
Wend
%>
//горния цикъл отпечатва всяко име на песен RSongs(i) от съответния албум -
//Album_ID=i през един ред, докато не е празна променливата RSongs
</td></tr>
</table>
. . . *
</body>
</html>
* Целия код на това asp можете да разгледате в Приложение В
<%
user =Session("user")
//на променливата user се присвоява стойността от изпълнението на предното
//asp и по-точно частта, отговаряща на потребител - user. Използват се сесии, за
//да е възможно последващото изпълнение на същата стойност - име на
//потребител - в следващото asp
pass = Session("pass")
//аналогично на потребител, в променливата pass се пази паролата на този
//потребител
Al_Id = request.QueryString("Al_Id")
//на променливата Al_Id се присвоява номера на албума, получен след
//изпълнението на предното asp
... *
insertSQL = "INSERT INTO basket VALUES ('" & user &"',"& Al_Id &")"
//в таблица basket в базата данни се вмъкват името на потребителя и номерата на
албумите, които е поръчал
%>
<html>
... *
<%
set newRow =server.CreateObject("ADODB.Recordset")
//вмъква се нов ред в базата дании
cn.Execute insertSQL
//изпълнява се горната SQL заявка
Response.Redirect "log.asp?user="& user &"&pass="& pass &""
//след изпълнение на заявката се препраща към log.asp със съответни стойности
//от на име на потребителя - user , и парола - pass - получени в резултат от
//изпълнението на това asp
%>
</body>
</html>
* Целия код на това asp можете да разгледате като видете source-то на add2basket.asp. A ако желаете да разгледате целия ASP пример самостоятелно, можете да го изтеглите от тук
Нека сега видим как стоят нещата при JSP страниците
В проектa, страници от който са обект на вниманието ни и който можете да разгледате само тук, е разработен сайт описващ една интересна услуга - изпращане на поздравителни картички по Интернет. В реализация е обърнато внимание на един нов подход в областа на Web интерфейс към бази данни, а именно обектно-ориентиран подход за достъп до бази данни (чрез Java) плюс допълнителни възможности за работа с HTML форми.
Използвана е база данни на MySQL,както и същия сървър за бази данни. Таблиците, към които се осъществяват обръщения са:
Сайта може да се ползва само от регистрирани потребитрели. Услугите до които има достъп регистрирания потребител са:
Някои потребители имат администраторски права, които включват:
Толкова за базата данни. За читатели, желаещи да се запознаят по-подробно – да разгледат готовия пример. А сега ще обърнем малко внимание на осъществяването ан връзката с базата данни през web в тези JSP страници. Предполага се известна степен на знание на Java, HTML, SQL.
...
public class SQLExecutor {
//Изпълнява SQL заявка и връща ResultSet, като използва MySQL JDBC драйвер и се
връзва с локално пуснатия MySQL сървър с потребител root и без парола
public static ResultSet executeSQL(String sql) {
try {
System.out.println("SQL:" + sql);
Class.forName("org.gjt.mm.mysql.Driver");
// драйвер който се използва за връзка с базата
Properties userData = new Properties();
userData.setProperty("user", "root");
//установяване на параметър за потребителя user с име root
userData.setProperty("password", "");
//аналогично за парола password за потребителя
Connection con=DriverManager.getConnection("jdbc:mysql://localhost:3306/webdb",
userData);
//свързване към сървъра
Statement query=con.createStatement(); // заявка (query)
return query.executeQuery(sql);
//връща резултата от изпълнението на заявката (query)
} catch (Exception e) {
System.out.println(e);
return null;
}
}
}
Методът, даден по-долу конструира SQL select заявка по зададени колони (getColumns()), таблици (getTables()) и условия(conditions),ако заявката е от няколко таблици, тогава ще имаме зададени релации(getRelations()) между тях
String getSQL(String conditions) {
if (getRelations().length() == 0)
return
"SELECT " + getColumns() +
" FROM " + getTables() +
" WHERE " + conditions;
else
return
"SELECT " + getColumns() +
" FROM " + getTables() +
" WHERE (" + getRelations() + ") AND (" + conditions + ")";
}
abstract public void fillData(ResultSet rs);
abstract public String fillData(HttpServletRequest req);
abstract public void save();
}
А сега нека разгледаме как се интегрират класовете на Java, някои от които са разгледани по-по-горе в JSP страница. /Пълния код на тази страница може да намерите като разгледате класовете в готовия <a href="">пример</a>/
<HTML>
<head>
<%@ page contentType = "text/html; charset=windows-1251" %>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1251">
</head>
<%@ page import="java.util.*"%>
//импортване на java.util библиотека
<% Vector v;
//обявяваме променлива v - вектор, която е от java.util библиотека
String id = request.getParameter("id");
//на низова променлива id се присвоява стойност параметър, която е предадена от
предното jsp чрез post метод на HTTP
Category currentCat = null;
//прави се инстанция на класа Category
if (id != null)
currentCat = CategoryManager.GetCategoryByID(Integer.parseInt(id));
//Разглеждаме класа CategoryManager и по-точно метода на този клас –
//getCategoryByID. Той изважда от базата категория която съответства на
//зададено id, ако няма такава връща null
//Integer.parseInt - Превръща от string в integer полученото от post заявката на
//предното jsp id
if (id == null) {
v = CategoryManager.getCategoryElem(-1);
//Следва друг метод от същия клас - getCategoryElem ако няма в базата картички
//и категории които се намират в категория с id=id връща празен Vector.
} else {
v = CategoryManager.getCategoryElem(Integer.parseInt(id));
//иначе присвоява на вектора v от базата картички и категории които се
//намират в категория с id=id и връща Vector от всички картички и категории,
//които се намират в дадената категория
...
</HTML>