2005.01_PHP5 i Java – w jedności siła_[Java].pdf - Java - Kapy97

Techniki

PHP5 i Java

– w jedności siła

Dariusz Dębowczyk

Zmiany wprowadzone w PHP5 zbliżyły składnię

tego języka do tej znanej programistom Java.

PHP5 nie zamierza jednak konkurować

z platformą Sun Microsystems w walce

o rynek korporacyjny – stanowi jej doskonałe

uzupełnienie.

językiem ściśle wyspecjalizo-

wanym pod kątem tworzenia

aplikacji WWW. Kolejne jego wersje

podbiły szturmem rozwijające się

dopiero obszary zastosowań Interne-

tu – PHP3 pozwalał w prosty sposób

budować dynamiczne strony WWW,

zaś mocno rozwinięty PHP4 stał się

najpopularniejszym na świecie języ-

kiem programowania aplikacji interne-

towych.

Łatwość programowania i elastycz-

ność, w połączeniu z ogromnymi możli-

wościami, doprowadziły do tego, że PHP

z prostego języka skryptowego używa-

nego kiedyś przez amatorów do reali-

zacji liczników i ksiąg gości na stronach

domowych, wyewoluował w kierunku

poważniejszych zastosowań, takich jak

systemy e-commerce, irmowe intranety

i systemy zarządzania treścią, aplikacje

e-learning oraz bazy danych dla przed-

siębiorstw.

Javę można uznać za następcę C++.

Jest językiem do zastosowań ogólnych,

choć ze względu na swoją specyikę na

początku był stosowany do tworzenia

oprogramowania sieciowego. Wkrótce

opanował takie obszary zastosowań jak

bazy danych oraz integracja systemów

informatycznych. Dzięki silnemu wspar-

ciu gigantów na rynku IT (m.in. IBM, Sun,

Oracle, BEA) Java stała się dominującą

platformą budowy korporacyjnych roz-

wiązań informatycznych.

W Javie powstają zintegrowane sys-

temy do zarządzania przedsiębiorstwami

(ERP), systemy zarządzania produkcją

(MRP), systemy do zarządzania relacja-

mi z klientami (CRM), jak również roz-

wiązania wertykalne, a więc skierowane

do konkretnych branż (bankowość, ubez-

pieczenia, telekomunikacja, przemysł).

Javę stosuje się również do wytwarzania

oprogramowania takiego jak węzły inte-

gracyjne, serwery aplikacyjne, serwery

HTTP, FTP, bazy danych, serwery pocz-

W SIECI

1. http://www.onjava.com/

pub/a/onjava/2003/10/15/

php_scalability.html

2. http://www.zend.com/zend/

art/php-over-java.php

3. http://java.sun.com/

4. http://java.sun.com/j2ee/

index.jsp

5 . http://www.jboss.org/

– strona projektu JBoss

(darmowy serwer

aplikacyjny J2EE)

6. http://www.theserverside.

com/ – serwis poświęcony

technologii Java i J2EE

7. http://www.

j2eeolympus.com/

freebooks/freej2eebooks.jsp

– darmowa biblioteka

książek dotyczących

technologii J2EE

www.phpsolmag.org

PHP Solutions Nr 1/2005

P HP od samego początku był

PHP5 i Java

Techniki

towe, środowiska programistyczne (naj-

popularniejsze środowisko tego typu dla

PHP – Zend Studio jest aplikacją napisa-

ną w Javie) i wiele innych. Firmy tworzą

w Javie aplikacje bazodanowe na własne

potrzeby, powstają w niej również korpo-

racyjne intranety i środowiska do pracy

grupowej. Jest także powszechnie stoso-

wana w oprogramowaniu wytwarzanym

w ramach prac badawczych oraz projek-

tów akademickich. Liczba jej zastosowań

jest ogromna – nie tylko w komputerach

stacjonarnych i na serwerach, ale rów-

nież w setkach milionów urządzeń prze-

nośnych (np. telefonów komórkowych).

Java została zaprojektowana jako

język stricte obiektowy. Faza kompilacji

i silna kontrola typów pozwalają wyelimi-

nować znaczną część błędów w kodzie

jeszcze przed wykonaniem programu.

Język ten wymaga znacznie większej

dyscypliny programowania niż PHP,

który nie wymusza deklaracji zmiennych,

ani określania ich typów.

PHP do dziś oferuje możliwość

programowania obiektowego jako alter-

natywę wobec sprawdzającego się

w prostszych aplikacjach podejścia

proceduralnego. PHP to język bardziej

elastyczny pozwalający programiście

na podejście ad hoc – prostą aplikację

webową można napisać i uruchomić

dosłownie w ciągu kilku do kilkunastu

minut. W przypadku Javy czas ten jest

z reguły wielokrotnie dłuższy.

Ale Java to nie tylko język, lecz rów-

nież (a może przede wszystkim) bardzo

złożone środowisko działania systemów

informatycznych, zdeiniowane stan-

dardem J2EE. Standard ten pozwala

wytwarzać wielowarstwowe, bazujące

na komponentach aplikacje, przenośne

pomiędzy serwerami aplikacyjnymi róż-

nych dostawców (choć w praktyce bywa

z tym różnie). Na rynku dostępnych jest

bardzo wiele implementacji J2EE. Naj-

bardziej znanymi serwerami aplikacyjny-

mi zgodnymi z J2EE są BEA WebLogic,

IBM Websphere, Sun Java System Appli-

cation Server (znany kiedyś jako Sun

One) i Oracle Application Server. Istnieją

również produkty open source, spośród

których najbardziej znanym jest JBoss

Application Server.

J2EE stanowi w praktyce roz-

budowany, stosunkowo spójny zbiór

specyikacji opisujących usługi oraz

Wybrane możliwości oferowane przez platformy J2EE

Kluczowy element platformy Java stanowi specyikacja J2EE, która deiniuje szereg

nisko- i wysokopoziomowych usług warstwy pośredniej (ang. middle tier ) oferowanych

programistom. Należą do nich m.in.:

• usługi zuniikowanego dostępu do baz danych (JDBC), oferujące szereg cech

niedostępnych w sterownikach baz danych dla PHP – w tym: monitoring realizowa-

nych poleceń SQL, rozkładanie zapytań do bazy na wiele serwerów, pule połączeń

(pozwalające uniknąć każdorazowego łączenia się z bazą danych),

• usługi nazw i katalogów (JNDI) pozwalające na dostęp do usług katalogowych

i zasobów przez nie udostępnianych (w J2EE mogą to być np. źródła danych),

• usługi transakcyjne (JTA) pozwalające realizować skomplikowane schematy trans-

akcyjne (w tym transakcje rozproszone, na wielu zasobach),

• usługi dostępu do kolejek komunikatów (JMS) umożliwiające współpracę z serwe-

rami kolejek komunikatów (np. MQ Series), a co za tym idzie – węzłami integracyj-

nymi, magistralami komunikatów,

• usługi ustandaryzowanego dostępu do tzw. systemów spadkowych (ang. legacy

system s), czyli starych systemów informatycznych stworzonych w wycofanych już

technologiach, które nadal pozostają w użyciu (JCA),

• usługi autentykacji, autoryzacji i bezpieczeństwa (JAAS) umożliwiające standa-

ryzację sposobu włączenia aplikacji do korporacyjnych mechanizmów kontroli

uprawnień,

• usługi instrumentacyjne (JMX) pozwalające na bieżąco zarządzać (monitorować

i konigurować, również automatycznie, bez ingerencji ludzkiej) zasobami aplikacji

(np. modyikować parametry serwera w zależności od obciążenia),

• usługi zegarowe (ang. scheduling services ) wyspecyikowane w najnowszej wersji

standardu J2EE, które pozwalają zarządzać wykonaniem zadań o określonym

czasie lub w zadanych cyklach czasowych.

Serwery aplikacyjne implementujące standard J2EE tworzą również środowisko do budowy

rozproszonych systemów opartych na standardowych komponentach EJB. Należy również

wspomnieć o możliwości współpracy aplikacji Java z brokerami komponentów CORBA.

API (interfejsy programistyczne), które

muszą oferować serwery aplikacyjne.

Serwery te stanowią środowisko dla

aplikacji J2EE oraz dostarczają usług

warstwy pośredniej (ang. middle tier

services – patrz: Ramka Wybrane

możliwości oferowane przez platformy

J2EE ). Dostępność tych usług i dojrza-

łość ich implementacji to istotne czynni-

ki decydujące o silnej pozycji rynkowej

platformy Java.

PHP nie jest w stanie konkurować

z Javą w zakresie zaawansowanych

rozwiązań warstwy pośredniej. Jego siłą

natomiast jest specjalizacja – powstał

z myślą o programowaniu dynamicznych

stron WWW i o budowie oprogramo-

wania dostępnego za pośrednictwem

przeglądarki internetowej sprawdza się

doskonale.

Najczęściej stosowaną w Javie tech-

niką budowy warstwy prezentacji aplika-

cji internetowych są strony JSP (Java

Server Pages), przy czym od niedawna

Sun promuje nowy standard – JSF (Java

Server Faces). Istnieje również szereg

niestandardowych rozwiązań, jak choćby

Velocity, Tapestry czy Echo. Wszystkie te

technologie mają swoje zalety, jednak na

bazie doświadczeń z większością z nich

możemy stwierdzić, że z żadną nie pra-

cuje się tak prosto i intuicyjnie jak z PHP

w połączeniu ze Smarty jako silnikiem

szablonów (ang. template engine ).

Nie przesadzając zbytnio można sza-

cować, że wysiłek związany z wytwarza-

niem w PHP aplikacji dostępnych przez

przeglądarkę internetową jest co naj-

mniej kilkakrotnie niższy niż w przypad-

ku Javy. Wiąże się to zarówno z samą

konstrukcją języka (np. brak koniecz-

ności konwersji typów), jak i modelem

wytwarzania (brak fazy kompilacji, moż-

liwość bezpośredniego wykonywania

kodu źródłowego), ale również z prostotą

samego cyklu życia aplikacji – program

jest odczytywany wprost z kodu źró-

dłowego, wykonywany, a następnie

usuwany z pamięci serwera. Obsługa

równoczesnych żądań jest odizolowa-

na, nie występują więc problemy typowe

dla programów współbieżnych. Znacznie

upraszcza to konstrukcję interpretera,

który w przypadku PHP jest niewielkim,

błyskawicznie uruchamiającym się pro-

gramem. Tworzenie, testowanie i popra-

wianie kodu odbywa się dzięki temu

znacznie szybciej.

PHP Solutions Nr 1/2005

www.phpsolmag.org

Techniki

PHP5 i Java

oraz pod kontrolą wszystkich wiodą-

cych systemów operacyjnych (w tym:

Windows, Linux, odmiany Uniksa), dla

których istnieją implementacje interpre-

tera PHP, a w wypadku Javy – maszyny

wirtualnej JVM. Programy PHP i Java

mogą zatem bez żadnych modyikacji

współpracować ze sobą w różnych śro-

dowiskach.

Rysunek 1. Szkic rozwiązania pozwalającego wykorzystywać usługi J2EE

w aplikacji PHP

Skalowalność

Niektórzy przeciwnicy PHP twierdzą,

że jego główną wadą jest brak skalo-

walności. Java jest wybierana przez

korporacje właśnie ze względu na sto-

sunkowo łatwe skalowanie rozwiązań

budowanych w oparciu o serwery apli-

kacyjne J2EE. Czy duże irmy powinny

obawiać się wyboru PHP ze względu na

możliwość stworzenia wąskiego gardła

w systemie? Innymi słowy – czy to

prawda, że PHP się nie skaluje?

Skalowalność to taka cecha syste-

mu informatycznego, która mówi nam,

jak bardzo jesteśmy w stanie zwiększać

jego zdolność do pracy w warunkach

rosnącego obciążenia (np. wzrostu

liczby korzystających z niego jednocze-

śnie użytkowników, czy też liczby żądań,

jakie jesteśmy w stanie zrealizować

w jednostce czasu) poprzez zwiększa-

nie zasobów sprzętowych. W najprost-

szym przypadku oznacza to po prostu

zwiększanie mocy procesora (lub liczby

procesorów) oraz rozmiaru pamięci

na serwerze. Zwiększanie możliwości

pojedynczej maszyny ma jednak swoje

granice (wyznaczone przez maksymal-

ną częstotliwość taktowania obecnych

procesorów oraz rozmiar pojedynczych

kości pamięci, jak również możliwości

obsłużenia tej pamięci przez system

operacyjny). Aby pokonać te ograni-

czenia, można utworzyć tak zwaną

farmę, czyli zbiór serwerów, na których

znajdują się kopie aplikacji. Niezbędne

jest wówczas również urządzenie (load

balancer) lub komputer z odpowiednim

oprogramowaniem, którego zadaniem

jest równoważenie obciążenia. Przy-

chodzące żądania są przekierowywane

do kolejnych maszyn w farmie. Wraz

ze wzrostem zapotrzebowania na moc

dodaje się następne serwery w celu roz-

łożenia zwiększonego ruchu.

Zbudowanie takiego rozwiązania

na potrzeby aplikacji w PHP nie stano-

wi problemu – szczegółowe informacje

na ten temat można znaleźć w artykule

Współpraca

Powyższe obserwacje prowadzą do

oczywistego wniosku – warto połączyć

mocne strony obu technologii. Serwe-

ry aplikacyjne Java dostarczają usług

niedostępnych PHP, z kolei ten ostatni

znacznie lepiej nadaje się do prac zwią-

zanych z oprogramowaniem interfejsu

użytkownika aplikacji. Wyobraźmy sobie

sytuację, w której moglibyśmy korzy-

stać z potężnej infrastruktury J2EE za

pośrednictwem tak prostego i wygodne-

go narzędzia, jakim jest PHP...

Autorzy interpretera PHP (Zend

Technologies) oraz stojąca za Javą kor-

poracja Sun Microsystems dostrzegli już

korzyści z połączenia sił. W ramach JCP

(Java Community Process) prowadzone

są obecnie prace nad specyikacją JSR-

223 standaryzującą obsługę języków

skryptowych (ze szczególnym uwzględ-

nieniem PHP!) w ramach platformy Java.

Mają one na celu ułatwienie integracji

obu technologii, m.in. dzięki zdeiniowa-

niu jednolitego sposobu dostępu skryp-

tów do obiektów środowiska Java (np.

obiektu zapytania HTTP).

Współpraca tych środowisk jest

możliwa już teraz. Oprócz podejść bez-

pośrednich, takich jak PHP Enabler for

Sun Java System Web Server zaprezen-

towanego ostatnio przez Zend Techno-

logies, czy istniejącej w PHP od dawna

możliwości pracy z obiektami Javy, ist-

nieje jeszcze jedna interesująca droga

integracji. Jest nią wykorzystanie proto-

kołu SOAP lub, w uproszczonej wersji,

wymiana danych poprzez wywołania

typu XML-over-HTTP. Rozwiązanie to

nabrało sensu dzięki nowościom wpro-

wadzonym w PHP5 – SimpleXML dra-

matycznie ułatwiającemu pracę z XML

oraz wbudowanemu klientowi (ale rów-

nież serwerowi) SOAP.

Szkic przedstawiający w bardzo

ogólny sposób realizację takiej współpra-

cy przedstawiliśmy na Rysunku 1. Zmu-

szenie obu platform do współdziałania

wymaga (zarówno w przypadku SOAP

jak i XML-over-HTTP) nieco zachodu

– niezbędne jest napisanie kodu obsłu-

gującego komunikację. Nie jest to aż tak

proste, jak utworzenie obiektu, wywo-

łanie jego metody i skorzystanie ze

zwróconego przez nią rezultatu, lecz –

szczególnie w przypadku SOAP – nieco

bardziej skomplikowane. Wiele wskazuje

na to, że technologia Web Services ma

przed sobą długą i dobrze zapowiadają-

cą się przyszłość. Wydaje się więc, że to

dość bezpieczny wybór i ciekawa alter-

natywa dla niskopoziomowej integracji

obu technologii.

Przenośność aplikacji

Programy napisane w obu językach są

przenośne na poziomie kodu wykony-

walnego – dla PHP jest to po prostu kod

źródłowy programu, zaś dla Javy – pro-

gram skompilowany do postaci binarnej.

Można je wykonywać na wielu typach

platform sprzętowych (PC, maszyny

serwerowe z różnymi rodzajami proce-

sorów, a nawet komputery mainframe)

www.phpsolmag.org

PHP Solutions Nr 1/2005

PHP5 i Java

Techniki

Tabela 1. Porównanie mocnych i słabych stron obu platform

Mocne strony

Słabe strony

wyspecjalizowany do programowania aplikacji

dostępnych przez przeglądarkę

brak wsparcia dla zaawansowanych usług warstwy

pośredniej (np. obsługi kolejek komunikatów

oraz monitorów transakcyjnych)

szybki cykl wytwórczy

(brak fazy kompilacji i restartu aplikacji)

nieprzystosowany do programowania aplikacji typu serwer

PHP

prosty model programowania

cykl życia aplikacji związany z obsługą żądania (program

przestaje istnieć w pamięci po zakończeniu obsługi żądania)

łatwość generowania kodu wykonywalnego

oraz wykonywania go

platforma mniej rozpoznawalna na rynku,

mniejsze zaufanie dużych irm

dostęp do zaawansowanych technologicznie

usług warstwy pośredniej

wieloetapowy i czasochłonny proces wytwórczy

– fazy kompilacji, ulokowania (ang. deployment )

oraz restartu aplikacji po wykonaniu każdej zmiany w kodzie

możliwość budowy wielowątkowych rozwiązań serwerowych

mało wygodne programowanie warstwy prezentacji

(tagi JSP), konieczność oczekiwania na kompilację stron JSP

Java

cykl życia programu nie związany z obsługą żądania HTTP

wysoka złożoność technologiczna,

opanowanie wymaga dużej ilości czasu

wsparcie gigantów rynku IT (IBM, Sun, BEA, Oracle i inni),

zaufanie dużych korporacji

wysokie zużycie zasobów przez elementy platformy (duża

zajętość pamięci, długie czasy uruchamiania się i restartu

serwerów aplikacyjnych), a przez to mniej wygodna praca

na stacjach roboczych programistów

The PHP Scalability Myth opublikowa-

nym jesienią ubiegłego roku na stronie

http://www.onjava.com/pub/a/onjava/

2003/10/15/php_scalability.html . Autor

tekstu, Jack Herrington, obala w nim

tezę o braku możliwości skalowania

aplikacji napisanych w PHP. Firmy, które

wybierają PHP jako element swojej

infrastruktury IT mogą być więc pewne,

że takie rozwiązania będzie można roz-

wijać wraz ze wzrostem ich potrzeb.

com oprogramowania unikalne możliwo-

ści, dzięki którym uzyskały bardzo silne

pozycje w swoich obszarach zastoso-

wań, a także uznanie ogromnych spo-

łeczności użytkowników. Problem w tym,

by twórcy aplikacji zdecydowali się na

wypróbowanie możliwości, jakie niesie

ze sobą połączenie tego, co najlepsze

z obu światów. n

Podsumowanie

Nie powinno budzić wątpliwości, że PHP

i Java nie stanowią dla siebie konkuren-

cji. Obie technologie są przenośne, ska-

lowalne, dojrzałe i mają dobre wsparcie

komercyjne. Każda z nich oferuje twór-

PHP Solutions Nr 1/2005

www.phpsolmag.org

2005.01_PHP5 i Java – w jedności siła_[Java].pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: