PRZEDMIOT:

:

Przygotował:
Rafał Kasprzyk

Aplikacje

Internetowe

Infrastruktura na której

działa WebApp

Rafał KASPRZYK

2

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

3

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

4

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

7

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

8

Dobre praktyki – jak jedno z

drugiego wynika

Rafał KASPRZYK

9

Rafał KASPRZYK

10

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

Rafał KASPRZYK

11

Zwartość

Niska
zwartość

Wysoka
zwartość

Sprzężenie

Rafał KASPRZYK

12

Fasada

Rafał KASPRZYK

13

Fasada - przykład

Rafał KASPRZYK

14

Fasada - przykład

Rafał KASPRZYK

15

Proxy

Rafał KASPRZYK

16

Proxy

Rafał KASPRZYK

17

MVC PATTERN

Rafał KASPRZYK

18

LAYERS PATTERN

Rafał KASPRZYK

19

Technologie J2EE w

warstwach

Rafał KASPRZYK

20

Wydział Cybernetyki WAT

Architektura systemu – przykład

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

22

Komunikacja w sieci

Rafał KASPRZYK

23

1

2

3

4

5

6

7

8

1

2

4

3

5

6

7

- stos

- stos

- stos

8

- 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

24

Klient

Komponent

encyjny

Obiekt

transferowy

Sieć

Transfer Object

Rafał KASPRZYK

25

Transfer Object

Rafał KASPRZYK

26

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

27

Klient

Komponent

sesyjny

Fasada

sesji

Sieć

Session Facade

Rafał KASPRZYK

28

Session Facade

Rafał KASPRZYK

29

Session Faced – przykład

Rafał KASPRZYK

30

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

31

DAO

Rafał KASPRZYK

32

DAO

Rafał KASPRZYK

33

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

34

Inversion of Control (IoC)

„Don’t call us we’ll call you”

Rafał KASPRZYK

35

Wstrzykiwanie zależności



Rysunek przedstawia klienta i serwer
przygotowane do wykorzystania
wzorca wstrzykiwania zależności

Rafał KASPRZYK

36

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

37

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

38

IoC – przykład (1/5)

Rafał KASPRZYK

39

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

40

IoC – przykład (3/5)

Rafał KASPRZYK

41

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

42

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

43

Budowa App z

wykorzystaniem IoC

Rafał KASPRZYK

44

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

45

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

47

Dostawca
usługi

Konsument

Interfejs

SOA w zarysie

Rafał KASPRZYK

48

Kroki implementacji aplikacji rozproszonej

zgodnie z SOA

1.

Implementacja komponentu usługowego
w dowolnym języku programowania

2.

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

3.

Zgłoszenie komponentu do centralnego
rejestru (UDDI)

4.

Wyszukanie komponentu w centralnym
rejestrze (UDDI)

5.

Wygenerowanie kodu komunikacyjnego
dla klienta (WebService Proxy)

6.

Implementacja klienta dla komponentu
usługowego

Rafał KASPRZYK

49

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

50

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

51