Technologie portali internetowych

Cele budowy WebApp



Zwiększenie przepustowości systemu
poprzez rozproszenie przetwarzania pomiędzy
wiele komputerów



Zwiększenie niezawodności systemu poprzez
replikację komponentów w wielu lokalizacjach



Odciążenie komputera użytkownika
końcowego dzięki przeniesieniu ciężkiego
przetwarzania na stronę serwera aplikacji



Współdzielenie komponentów przez różne
aplikacje pracujące we wspólnych środowisku
sieciowym

Rafał KASPRZYK

Zastosowanie WebApp



Portale internetowe



Aplikacje internetowe przeznaczone dla dużej liczby
użytkowników. Kluczowym zagadnieniem jest sposób
redagowania treści, a także możliwość definiowania wyglądu
stron wchodzących w skład portalu.



Portale korporacyjne



Systemy, które przechowują informacje związane z działalnością
firmy i z założenia dostępne są tylko dla pracowników firmy. W
wielu przypadkach dostęp do portali jest możliwy także poprzez
Internet za pośrednictwem połączenia szyfrowanego.



Systemy obsługi klientów



Aplikacje dostępne przez Internet, w której klienci mogą złożyć
zamówienie na produkt lub usługę i dowiedzieć się o stanie
realizacji.



Systemy CMS i/lub WCM



Umożliwiają obsługę wielu użytkowników i różnych poziomów
uprawnień.



Inne

Rafał KASPRZYK

Zalety WebApp



Uniwersalność rozwiązania



Niskie koszty instalacji



Proste zarządzanie



Niskie wymagania sprzętowe



Bezpieczeństwo



…

Wady WebApp?



Głównym argumentem zwolenników

aplikacji klasycznych (desktopowych)

jest „szybkość działania interfejsu”,

która przy wykorzystaniu przeglądarki

może być „denerwująco” niska.



Dzięki nowym technologiom budowy

interfejsu WebApp, które część zadań

odpowiedzialnych za komunikację

przerzucają z serwera na komputer

użytkownika, aplikacje internetowe

stają się wyjątkowo interaktywne.

Problemy WebApp



Elastyczność systemu



Jeśli architektura nie jest wystarczająco elastyczna
występują trudności z jej utrzymaniem i rozbudową



Komunikacja sieciowa



Opóźnienia w komunikacji mają wysoce negatywny
wpływ na ogólną wydajność systemu



Transakcyjność



Model transakcyjny zapewnia integralność danych w
systemach rozproszonych, jednakże ogranicza
współbieżność przetwarzania



Kontrola kosztów



Większość problemów można uniknąć stosując
najsilniejsze serwery, najszybsze dyski, najnowsze
rozwiązania sieciowe, co prowadzi jednak do eskalacji
kosztów

Rafał KASPRZYK

Rozwiązywanie problemów



Samo w sobie rozwiązywanie problemów

przynosi dużo satysfakcji, ale nie jest

uzasadnione „biznesowo”



Wzorce istotnie obniżają koszty

rozwiązywania problemów



Obowiązkiem twórcy aplikacji sieciowych

jest znajomość wzorców



Poznaj katalogi wzorców!



Poznaj wzorce!



Zdobądź umiejętność definiowanie problemów!

Rafał KASPRZYK

Jakoś modelu obiektowego



Zwartość (ang. cohesion)



Miara, jak bardzo klasa lub grupa klas przyczynia

się do realizacji określonego celu



Należy dążyć do jak największej zwartości



Klasy (lub grupy klas) powinny być skupione na realizacji

określonego celu – zazwyczaj jednego



Klasa, która realizuje kilka różnych zadań ma słabą zwartość



Sprzężenie (ang. coupling)



Miara, jak dwie lub więcej klas jest od siebie

wzajemnie zależnych



Należy dążyć do jak najmniejszego sprzężenia między

obiektami lub grupami obiektów



Obiekty powinny być od siebie zależne tylko w minimalnym

zakresie niezbędnym do realizacji określonych zdań



Jeśli zależność (liczne połączenia) między klasami jest duża,

trudno o dobre ponowne wykorzystanie kodu

Wzorce dla aplikacji

internetowych



Wzorce można podzielić według warstw,

których dotyczą



Warstwa prezentacji



Wzorce warstwy prezentacji ułatwiają wprowadzanie

modyfikacji wynikających ze zmiany wymagań

funkcjonalnych



Warstwa biznesowa



Wzorce warstwy biznesowej skupione są na poprawieniu

wydajności



Warstwa integracji



Wzorce warstwy integracji podnoszą elastyczność

aplikacji poprzez odseparowanie dziedziny biznesowej od

mechanizmów zapewniających trwałość obiektów

Rafał KASPRZYK

Komunikacja w sieci

Rafał KASPRZYK

- stos

- przesłanie

- obsługa

- akceptacja

- przesłanie

- stos

Optymalizacja komunikacji



Wzorzec Transfer Object (Value Object)



Wzorzec rozwiązuje problem dużej liczby wywołań

sieciowych przesyłających niewielkie porcje

informacji

Rafał KASPRZYK

Klient

Komponent

encyjny

Obiekt

transferowy

Sieć

Optymalizacja komunikacji



Wzorzec Session Facade



Udostępnia funkcjonalność systemu w

zgrupowanej postaci, co pozwala na zmniejszenie

liczby wywołań sieciowych oraz ograniczenie

liczby transakcji systemowych potrzebnych do

zrealizowania transakcji biznesowej

Rafał KASPRZYK

Klient

Komponent

sesyjny

Fasada

sesji

Sieć

Podnoszenie elastyczności

systemu



Wzorzec Data Access Objects



Zastosowanie wzorca DAO pozwala na istotne

zmniejszenie wpływu zmiany fizycznej struktury

danych na kod aplikacji. W takiej sytuacji

wystarczy zmodyfikować ograniczoną grupę klas

wzorca DAO – hermetyzujących kod dostępu do

danych



Obiekty DAO zamykają w sobie szczegóły

współpracy

z danym źródłem danych udostępniając

warstwie biznesowej jednolity interfejs dostępu

do danych w bazie danych lub systemach

spadkowych



Wzorzec DAO gromadzi logikę dostępu do

danych

w jednym miejscu aplikacji

Rafał KASPRZYK

Jak radzić sobie z „obsługą

zależności”?



Jeśli aplikacja ma robić „cokolwiek”, to
zależności pomiędzy jej składowymi muszą się
pojawić



Cała sztuka polega na tym, aby zidentyfikować
zależności i obsłużyć je w prosty sposób



Sposób implementacji zależności ma wpływ
na:



Łatwość tworzenia aplikacji



Możliwość rozbudowy aplikacji



Sposób testowania

Rafał KASPRZYK

Wstrzykiwanie zależności



Klient używa pewnej Usługi



Klient posiada własność, w której można

zapisać referencję do Usługi



Usługa jest reprezentowana przez

interfejs



Faktyczna implementacja nie jest znana



Dodatkowe narzędzie (asembler,

kontener), odpowiada za utworzenie

Klienta i Usługi, a następnie określenie

wartości własności (będącej referencją do

obiektu klasy Usługa stanowiącego

implementację usługi)

Rafał KASPRZYK

Jak to zrobić?



Aby stosować przedstawiony wzorzec
projektowy należy wykonać trzy
czynności:



Utworzyć interfejs reprezentujący usługę



Zaimplementować interfejs



Dodać do klienta właściwość odwołującą
się do usługi przez jej interfejs



Przy wykorzystaniu dodatkowego
narzędzi lub własnego kodu stworzyć
usługę i przypisać odpowiednią wartość
właściwości najlepiej deklaratywnie

Rafał KASPRZYK

IoC – przykład (2/5)

public interface

MovieFinder

{

List findAll();

}

class

MovieListener

{

    private MovieFinder finder;
    public MovieLister() {
        finder = new

ColonDelimitedMovieFinder

("movies1.txt");

    }
    public Movie[ ] moviesDirectedBy(String arg) {
        List allMovies = finder.findAll();
        for (Iterator it = allMovies.iterator(); it.hasNext();){
            Movie movie = (Movie) it.next();
            if (!movie.getDirector().equals(arg)) it.remove();
        }
        return (Movie[ ])allMovies

.toArray(new Movie[allMovies.size()]);

}

Rafał KASPRZYK

IoC – przykład (4/5)

class

MovieListener

{

private MovieFinder finder;

public void setFinder(MovieFinder finder) {
this.finder = finder;
}
public Movie[ ] moviesDirectedBy(String arg) {…}

}

class

ColonDelimitedMovieFinder

implements …{

  public void setFilename(String filename) {
   this.filename = filename;
  }
}

Rafał KASPRZYK

IoC – przykład (5/5)

<beans>
<bean id="

MovieListener

" class="package.MovieListener">

            <property name="finder">
                <ref bean="MovieFinder"/>
            </property>
        </bean>
        <bean id="

MovieFinder

" class="package.ColonDelimitedMovieFinder">

            <property name="filename">
                <value>movies1.txt</value>
            </property>
        </bean>
</beans>

public void testSpringContainer() {

ApplicationContext ctx =
new FileSystemXmlApplicationContext("beans.xml");

MovieListener

movieListener =

(MovieListener) ctx.getBean("MovieListener");

Movie[ ] movies = movieListener.moviesDirectedBy("Sergio Leone");
}

beans.xml

Rafał KASPRZYK

Budowa App z

wykorzystaniem IoC

Rafał KASPRZYK

Kontener

IoC

Aplikacja

Obiekty JAVA

Konfiguracja

Projektowanie architektury



Pojęcie technologii



Całokształt wiedzy dotyczącej konkretnego sposobu

wytwarzania jakiegoś dobra lub uzyskania określonego

efektu.



Pojęcie platformy



Szczegóły technologiczne i inżynierskie, które nie mają

ścisłego związku z biznesową funkcjonalnością aplikacji



Infrastruktura usługowa na którą składają się liczne
technologie umożliwiające budowę złożonych aplikacji



Wykorzystanie szablonów (ang. frameworks)



Szablon – częściowo kompletny system. Definiuje

architekturę dla podsystemu oraz określa z jakich

bloków i modułów powinna składać się aplikacja



Szablony powstają poprzez zaimplementowanie i

złożenie współpracujących ze sobą wzorców

projektowych i wzorców architektury

Rafał KASPRZYK

Platformy



J2EE



Microsoft .NET



LAMP



Linux, Apache, MySQL i

PHP/Phyton/PERL



Ruby on Rails



…

Idea SOA



Trzy słowa klucze definiujące SOA:



Serwisy



Reprezentacja biznesowej funkcjonalności



Interoperacyjność



SOA mówi jak uwzględnić interoperacyjność przy
projektowaniu



Luźne połączenia



SOA nie mówi jak to robić, a jedynie że tak powinno być

Rafał KASPRZYK

Dostawca
usługi

Konsument

Interfejs

Kroki implementacji aplikacji rozproszonej

zgodnie z SOA

Implementacja komponentu usługowego
w dowolnym języku programowania

Sporządzenie pliku opisu interfejsu usługi
(WSDL)

Zgłoszenie komponentu do centralnego
rejestru (UDDI)

Wyszukanie komponentu w centralnym
rejestrze (UDDI)

Wygenerowanie kodu komunikacyjnego
dla klienta (WebService Proxy)

Implementacja klienta dla komponentu
usługowego

Rafał KASPRZYK

Co mówi GARTNER



Dlaczego warto poznać SOA



“By 2008, SOA will be a prevailing software
engineering practice, ending the 40-year
domination of monolithic software
architecture (0.7 probability)”



SOA i WebServices



SOA nie potrzebuje Web Services



Nie każdy Web Service budowany jest dla
SOA



But… ”Through 2008, SOA and Web services
will be implemented together in more than 75
percent of new SOA or Web services projects
(0.7 probability)”

Rafał KASPRZYK

Podsumowanie SOA



Dlaczego warto zająć się SOA?



Prawdopodobna przyszłość oprogramowania (wsparcie
gigantów)



Najlepsze na chwilę obecną podejście do integracji



Idealnie pasuje do modelowania procesów biznesowych



Łatwość wprowadzania zmian – istotne dla biznesu!



cohesion, loose coupling, coarse grained,



Nowe ideologie – np. Metropolis



Dlaczego jeszcze nie teraz…



Brak standardów komunikacji pomiędzy
przedsiębiorstwami



Główna technologia, na której SOA bazuje
(WebServices) ciągle jest niedoskonała.



Trudności ze współpracą środowisk programistycznych.



Niedojrzałe „best practices”

Rafał KASPRZYK

Document Outline