Hybrydowe  aplikacje  webowe  

¡  Aplikacje  webowe  –  klasyczne  i  mashups   ¡  Architektura   ¡  Technologie  

2

¡  ¡ 

Etap  zero:  

§  Document-­‐centric,  statyczny  

Etap  (-­‐)1  

§  Pojawiają  się  języki  skryptowe,  applety  Java   §  „Wodotryski”  wykonywane  po  stronie  klienta    

¡ 

Etap  2  

§  Powiązania  z  bazą  danych  –  dostęp  do  aplikacji  za  pomocą  przeglądarki  

¡ 

Etap  3  

§  Dołączanie  semantyki  do  danych  (XML)   §  Rozpraszanie  przetwarzania  

¡ 

Etap  4  

§  Asynchroniczna  komunikacja  (Ajax)   §  Rich  Internet  Applications  (RIA)  –  on-­‐screen-­‐applications     ▪  Adobe  Flash,  Adobe  Air,  GWT,  Microsoft  Silverlight,    JavaFX,  …  

§  „Web  2.0”  

¡ 

Etap  5  

§  Mashup    

¡ 

Etap  …  

§  Cloud  Computing?  

3

HTML,  JavaScript,   CSS,  DOM,  Ajax,   Action  Script,  …  

Protokoły:  HTTP,   SOAP,  REST,   Atom,  RSS,  …  

PHP,  Java,  .NET,   Python,  Ruby,  Groovy,   XSLT,  Perl,  …  

Formaty:   HTML  ,  XML,   JSON,  …  

4

¡  Java  Platform,  Enterprise  Edition   §  Platforma  programowania  po  stronie  serwera  w  języku  

Java   §  Uzupełnia  platformę  Java  SE  o  biblioteki  umożliwiające   budowanie  aplikacji:     ▪  wielowarstwowych,  rozproszonych,  odpornych  na  awarie  

§  Które  bazują  na  komponentach  działających  w  

obrębie     ▪  Serwera  aplikacji  

¡  Zdefiniowana  jako  specyfikacja   6

¡  W  ramach  JEE  istnieje  wiele  specyfikacji  API     §  JDBC  (Java  Database  Conectivity),  RMI  (Remote  

Method  Invocation),  JMS  (Java  Message  Service),   WS  (Web  Services),  XML   §  EJB  (Enterprise  Java  Bean),  servlet,  portlet,  JSP   (Java  Server  Pages),  JSF  (Java  Server  Faces),  JPA   (Java  Persistence  API),  JTA  (Java  Transaction  API)   §  CDI  (Context  and  Dependency  Injection)  

7

¡  Całość  specyfikacji   §  GlassFish  (GlassFish  Community)   §  JBoss  (Red  Hat)     §  Oracle  WebLogic  (Oracle)   §  Apache  Geronimo  (Apache  Software  Foundation)   §  IBM  WebSphere  (IBM)   §  ColdFusion  (Adobe)   ¡  Kontenery  webowe  (servletów)   §  Apache  Tomcat  (Apache  Software  Foundation)   §  Jetty  (Eclipse  Foundation)   8

9

¡  Plik  WAR  (web  archive)   Deployment   descriptor  

10

¡  ¡  ¡  ¡  ¡  ¡  ¡  ¡ 

Kontener  tworzy  instancję  servletu  (przy  pierwszym   odwołaniu  lub  przy  starcie)   Konfiguracja  ładowana  z  pliku  web.xml   Jedna  instancja  servletu  współdzielona  przez  klientów   Request  uruchamia  metodę  service(),  która  wywołuje   metodę  doPost()  lub  doGet()   Pomiędzy  kontenerem  a  servletem  mogą  znajdować   się  filtry  (transformacja  requestu)   Servlet  może  przekazać  request  innemu  servletowi   (forward)   Servlet  tworzy  obiekt  odpowiedzi  (response)   Podczas  usuwanie  servletu  wołana  jest  metoda   destroy()  

11

12



SecurityServlet pl.lodz.p.kis.ksoir.servlet.SecurityServlet SecurityServlet /* ImageServlet pl.lodz.p.kis.ksoir.servlet.ImageServlet ImageServlet /images/*

13

¡  Aplikacja  oparta  o  servlet  może  korzystać  z  

innych  technologii  (API),  niekoniecznie   związanych  z  API  definiowanymi  w  ramach   JEE.  

§  Mechanizmy  generacji  widoku  np.   ▪  JSP,  JSF  -­‐>  Apache  Struts,  Apache  Wicket,  Spring  MVC   §  Mechanizmy  implementacji  modelu     ▪  EJB  -­‐>  Spring  Framework  

¡  Servlet  może  do  generowania  widoku  użyć  

np.  JSP,  robiąc  do  niego  forward  requestu    

14

15

¡  Cykl  życia  aplikacji  webowej   §  Opracowanie  kodu  komponentu   §  Opracowanie  deskryptora  rozmieszczenia  

(deployment)   §  Kompilacja  aplikacji     §  Pakowanie  kodu  aplikacji  (WAR)     §  Rozmieszczenie  na  serwerze  aplikacji   §  Dostęp  z  wykorzystaniem  URL   16

¡  RFC  2616     ¡  Komunikaty   §  HTTP-­‐message  =  Request  |  Response  

¡  Request  (żądanie)   §  Method    Request-­‐URI    HTTP-­‐Version  

¡  Response  (odpowiedź)  

§  HTTP-­‐Version  Status-­‐Code  Reason-­‐Phrase  

18

¡  Metody  żądania  (request):   §  OPTIONS   §  HEAD   §  GET   §  PUT   §  POST   §  DELETE   §  TRACE   §  CONNECT   19

¡  GET     §  pobieranie  danych  wskazywanych  przez  Request-­‐

URI   §  implementacja  nie  powinna  generować  efektów   ubocznych  

20

¡ 

POST     §  informuje  serwer,  że    dane  zawarte  w  komunikacie  

powinny  zostać  dodane  jako  pod-­‐zasób  w  stosunku  do   zasobu  wskazywanego  przez  Request-­‐URI  ( jak  plik  w   stosunku  do  katalogu).     §  POST  miał  w  swoim  zamyśle  być  jednolitą  metodą  dla   operacji  typu:   ▪  Adnotowanie  istniejących  zasobów,     ▪  Wysłanie  wiadomości  do  forum,  grupy/listy  dyskusyjnej,  itp.   ▪  Przesłanie  bloku  danych  (przesłanie  formularza)  do  procesu   obsługi   ▪  Dodanie  rekordu  do  bazy  danych   21

¡  PUT   §  Informuje  serwer,  że  zawarte  dane  powinny  być  

zachowane  pod  wskazanym  URI  (referencja?).     §  Jeśli  identyfikator  Request-­‐URI  odnosi  się  do   zasobów  już  istniejących,  przesłane  dane  należy   uznać  za  ich  zmodyfikowaną  wersję.  Jeśli  Request-­‐ URI    nie  wskazuje  na  istniejący  zasób,  oraz  URI   może  zostać  zdefiniowane  jako  nowy  zasób,   serwer  może  utworzyć  zasób  z  przesłanym  URI   22

¡  DELETE   §  Żądanie  usunięcia  zasobu  wskazywanego  przez  

Request-­‐URI   §  Klient  nie  ma  gwarancji  usunięcia,  pomimo   potwierdzenie  sukcesu  przez  serwer   odpowiednim  kodem  statusu  

23

¡  POST  vs.  PUT   §  Wg  RFC  2616  podstawowa  różnica  pomiędzy  

POST  a  PUT  związana  jest  ze  znaczeniem  URI   ▪  Request-­‐URI  w  metodzie  POST  identyfikuje  zasób,  który   obsługuje  załączone  dane.  Zasobem  może  być  np.     proces,  protokół,  ….  Dane  są  parametrem  zasobu  (np.   metody).     ▪  Request-­‐URI  w  metodzie  PUT  identyfikuje  sam  zasób   (którego  dane  są  przesłane  w  komunikacie).  Serwer  nie   może  zastosować  tego  komunikatu  do  innych  danych   niż  wskazywane    przez  Request-­‐URI.     24

¡  Aplikacja  może  samodzielnie  decydować,  jak  

reaguje  na  poszczególne  metody  żądania,   zachowując  się  wbrew  zaleceniom  zawartym   w  RFC  2616    

25

¡ 

HTTP  jest  bezstanowy   §  GET  -­‐>  otwórz  połączenie,  pobierz  dane,  porzuć  

połączenie  

¡ 

Sesja  nie  jest  częścią  specyfikacji  HTTP,  jednak   aplikacje  webowe  nie  mogą  pracować  w  sposób   bezstanowy:   §  Aplikacje  webowe  muszą  zarządzać  sesją  (np.  koszyk  

w  sklepie  internetowym)   §  Sesja  przechowywana  na  serwerze  (obiekty  sesji,  baza   danych  –  długie  sesje)   §  Sesja  przechowywana  na  kliencie  (ciasteczka,  ukryte   pola  formularza)   26

¡  Aplikacja  webowa  łącząca  dane,  kod  i  inną  

zawartość  z  różnorodnych  źródeł  w   integralną  całość   ¡  W  czystej  postaci  mashup  wykonywany  jest   całkowicie  na  kliencie  (client-­‐side  mashup),   jednak  możliwa  jest  także  integracja  po   stronie  serwera  (server-­‐side  mashup)  

28

2. Pobranie danych

1. Żądanie

4. Odpowiedź

3. Przetwarzanie Utrzymywanie   własnych  baz  danych   dla  wszystkich  usług   składowych  

Wszystkie  usługi   hostowane  lokalnie     (i  zazwyczaj  napisane   samodzielnie)  

Kompletny  kod   strony  (HTML)  w   końcowej  postaci  

29

Przeglądarka   (klient)  komunikuje   się  z  dostawcami   usług  

Minimalna  liczba   własnych  usług   (optymalnie  -­‐  brak)  

3a. …

1. Żądanie 3b. … 2. Odpowiedź 3c. … Podstawowy  HTML   zawierający  fragmenty   JS  odpowiedzialne  za   komunikację  z  usługami   zewnętrznymi  

Odpowiedzi  zawierają   dane  przetwarzane  przez   JS  na  kliencie  lub   dynamicznie  budowane   skrypty  JS  odpowiedzialne   za  dalsze  akcje  

30

Część  usług  jest   integrowana  już  po  stronie   serwera  (kwestie   bezpieczeństwa,  ukrycia   implementacji,  CORS,  …)  

4a. …

2a. … 1. Żądanie 4b. … 3. Odpowiedź 2b. …

4c. … Kod  strony  może  być   całkowicie  kompletny  lub   odwoływać  się  przez  JS  do   kolejnych  usług   31

¡  Mashupy  serwerowe  są  znacznie  prostsze  w  

implementacji  w  porównaniu  z  klienckimi   ¡  Aspekty  prawne  i  licencyjne   ¡  Z  własnej  woli  „oddajemy”  swoje  dane   stronom  trzecim,  nie  mając  informacji   dotyczących  ich  bezpieczeństwa  i   składowania   ¡  Często  dostęp  do  danych  niemożliwy  poza   interfejsami  webowymi  

32

¡  Podstawowe  ograniczenie  stanowi  „polityka  

jednego  źródła”  (same  origin  policy)  

§  Ograniczenie  wynikające  z  reguł  bezpieczeństwa  

w  klientach  HTTP  (głównie  chodzi  o  historię  i   cookies),  uniemożliwiając  łączenie  klienta  z   zasobami  znajdującymi  się  na  innych  serwerach  

33

Przykładowy adres strony: http://www.example.com/dir/page.html URL  

Wynik   Powód  

http://www.example.com/dir/page.html  

OK  

Ten  sam  host,  port  I  protokół  

http://www.example.com/dir2/other.html  

OK  

Ten  sam  host,  port  I  protokół  

http://www.example.com:81/dir/other.html  

BŁĄD  

Inny  port  

https://www.example.com/dir/other.html  

BŁĄD  

Inny  protokół  

http://en.example.com/dir/other.html  

BŁĄD  

Inny  host  

http://example.com/dir/other.html  

BŁĄD  

Inny  host  

http://v2.www.example.com/dir/other.html  

BŁĄD  

Inny  host  

34

¡  CORS  (cross-­‐origin  resource  sharing)   §  Dołączanie  do  odpowiedzi  HTTP  specjalnego  

nagłówka  Access-­‐Control-­‐Allow-­‐Origin   §  Może  zawierać  listę  dozwolonych  domen  lub   pozwalać  na  wszystkie  (*)   §  Obsługa  nagłówka  nie  jest  zaimplementowana  w   starszych  przeglądarkach  

35

¡  Własność  document.domain   §  Jeżeli  dwie  ramki  (okna)  zawierają  JavaScript  

określające  tę  samą  domenę,  reguła  zostaje   zniesiona   §  Na  przykład,  współpracujące  skrypty  załadowane   z  hostów  orders.example.com  i   catalog.example.com  mogą  określić  wspólną   domenę  na  example.com   §  Sposób  użycia  –  ukryty  iframe  osadzony  na  stronie   36

¡  Cross-­‐document  messaging   §  Skrypty  z  oddzielnych  ramek  mogą  wysyłać  do  

siebie  komunikaty  poprzez  Window.postMessage()   §  Skrypt  „nasłuchujący”  musi  subskrybować   zdarzenia  obiektu  Window  poprzez  handler   onmessage   §  Skrypty  nadal  nie  mogą  odczytywać  własności   drugiej  ramki   §  Sposób  użycia  –  ukryty  iframe  osadzony  na  stronie   37

¡  JSONP  (JSON  with  padding)   §  Ograniczenie  polityki  jednego  źródła  nie  dotyczy  

znacznika    –  przeglądarka  może  korzystać   ze  statycznych  zasobów  (skrypty,  obrazki,  CSS)   znajdujących  się  na  różnych  maszynach   §  Wynik  działania  zdalnego  skryptu  to  JSON   „opakowany”  w  funkcję  dostępną  na  kliencie   §  Dzięki  obsłudze  DOM  przez  JS,  takie  skrypty   mogą  być  „wstrzykiwane”  na  stronę  dynamicznie   §  Działa  wyłącznie  z  HTTP  GET   38

¡  Asynchronous  JavaScript  and  XML   ¡  Pozwala  klientom  na  asynchroniczne  

wysyłanie  i  pobieranie  danych     ¡  Komunikacja  strony  z  serwerem  przebiega  „w   tle”,  nie  wpływając  na  jej  odbiór  przez   użytkownika  

40

¡  Zalety   §  Osiągnięcie  bardziej  dynamicznej  interakcji  bez  

konieczności  przeładowywania  całej  strony   internetowej   §  Kod  skryptowy  po  stronie  klienta  może  zostać   wykorzystany  do  pobierania  danych  z  serwera   poprzez  API,  bez  konieczności  przeładowywania   całej  strony  

41

¡ 

Wady  i  problemy   §  Problem  z  historią  przeglądarki  (kiedy  cała  strona  

ładowana  jest  dynamicznie,  np.  przez  Dojo)   §  Zakładki  (kiedy  cała  strona  ładowana  jest   dynamicznie,  np.  przez  Dojo)   §  Zależności  czasowe   §  Indeksowanie     §  Możliwy  brak  obsługi  JavaScript  w  przeglądarce   §  Polityka  tego  samego  źródła  (same  origin  policy)   §  Zwiększenie  liczby  requestów   §  JAWS  -­‐  Job  Access  With  Speech  

42

System synchroniczny

System asynchroniczny

43

44

¡  Do  komunikacji  używany  jest  obiekt  

XMLHttpRequest  (XHR)   ¡  XMLHttpRequest  podlega  same  origin  policy   ¡  Wbrew  nazwie  (wynikającej  z  początkowych   założeń  standardu),  AJAX  pozwala  na  użycie   innych  tekstowych  formatów  danych,  np.   JSON,  HTML,  plain  text  

45

¡ 

Dostęp  do  obiektu:  

function getHttpRequest() { var xhr = null; if (window.XMLHttpRequest) { // normalne przeglądarki xhr = new XMLHttpRequest(); } else if (window.ActiveXObject) { // IE < 7 try { xhr = new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) { try { xhr = new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) { alert("Your browser does not support Ajax."); } } } if (xhr.overrideMimeType) { xhr.overrideMimeType("text/xml"); // możliwość wymuszenia typu MIME } return xhr; }

46

¡ 

Wysłanie  żądania:  

var xhr = getHttpRequest(); var url = "http://my.host/my/service/url"; var async = true; var postContent = ”param1=value1¶m2=value2&...”; xhr.open("POST", url, async); // dozwolone inne metody HTTP xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded"); // xhr.setRequestHeader("nazwa", "wartość"); - nagłówki w miarę potrzeby xhr.send(postContent); xhr.onreadystatechange = function() { try { if (xhr.readyState == 4) { if (xhr.status == 200) { // mamy odpowiedź, możemy jej użyć } else { // inny kod odpowiedzi HTTP – co się stało? } } } catch (exception) { // obsługa błędu } }  

47

¡  Własności  XMLHttpRequest:   §  readyState  –  status  żądania  (od  0  do  4),   §  responseText  –  tekst  odpowiedzi  (plain  text),   §  responseXML  –  obiekt  XML  sparsowanej  odpowiedzi  

§  § 

(responseText  musi  być  prawidłowym  XML),   status  –  kod  odpowiedzi  HTTP  (np.  404),   statusText  –  opis  statusu  HTTP  (np.  „not  found”)  

48

¡  http://api.jquery.com/jQuery.ajax/     ¡  Uproszczone  metody  HTTP:   §  http://api.jquery.com/jQuery.get/     §  http://api.jquery.com/jQuery.post/     §  …  

49

¡  http://dojotoolkit.org/reference-­‐guide/1.8/

dojo/xhr.html       ¡  Uproszczone  metody  HTTP:  

§  http://dojotoolkit.org/reference-­‐guide/1.8/dojo/

xhrGet.html#dojo-­‐xhrget       §  http://dojotoolkit.org/reference-­‐guide/1.8/dojo/ xhrPost.html#dojo-­‐xhrpost       §  …   50

¡  JavaScript  Object  Notation   ¡  Standardowy  format  tekstowego  zapisu  

obiektów  w  JavaScript   ¡  Dostęp  do  zawartości  znacznie  łatwiejszy  niż   w  przypadku  XML  (bezpośrednia  konwersja   tekstu  do  obiektu):   §  JSON.parse(xhr.responseText);

52

var person = { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021" }, "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" } ] };

John Smith 25 21 2nd Street New York NY 10021 212 555-1234 646 555-4567

lub:

53

var person = { "firstName": "John", "lastName": "Smith", "age": 25, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021" }, "phoneNumber": [ { "type": "home", "number": "212 555-1234" }, { "type": "fax", "number": "646 555-4567" } ] }; var firstName = person.firstName; // lub person["firstName"] var homePhone = person.phoneNumber[0].number; // lub person["phoneNumber”][0]["number”] 54

¡  Web  services   ¡  Niezależna  od  platformy  metoda  komunikacji  

między  urządzeniami  lub  programami   ¡  Standard  W3C   ¡  WSDL  (Web  Services  Description     Language)   ¡  UDDI  (Universal  Description     Discovery  and  Integration)  

56

¡  ¡  ¡ 

Simple  Object  Access  Protocol   Używa  formatu  XML  i  protokołu  warstwy  aplikacji   (np.  HTTP  lub  SMTP)   „Wysłużony”  i  ciężki  w  użyciu  standard  (np.   konieczność  ciągłego  utrzymywania  WSDL   zgodnego  z  kodem)   POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn IBM

57

¡  Representational  State  Transfer   ¡  „Luźniejszy”  typologicznie  od  SOAP   ¡  Nie  stanowi  protokołu,  a  raczej  styl  

architektoniczy   ¡  Nie  wymaga  XML  (wspiera  dowolny  typ   MIME)   ¡  Nie  wymaga  nagłówka  HTTP  od  dostawcy   usługi   ¡  RESTful  web  services   58

¡  Brak  jednolitego  standardu   ¡  Każdy  zasób  jest  definiowany  przez:   §  URI   §  Typ  danych  (MIME)   §  Wspierane  operacje  (GET,  PUT,  POST,  DELETE)  

59

Zasób  (URI)  

GET  

PUT  

POST  

DELETE  

http://example.com/resources/     (wskazuje  całą  kolekcję)  

Pobierz  całą   kolekcję  

Zastąp  całą   kolekcję  

Utwórz  nowy   element  

Usuń  całą   kolekcję  

http://example.com/resources/item17   (identyfikuje  konkretny  element)  

Pobierz   element   (zgodnie  z   typem  MIME)  

Zastąp  (lub   utwórz)   element  

Utwórz  nowy   element   wewnątrz   wskazanego  

Usuń   wskazany   element  

http://example.com/parents/132/children/17   Pobierz  dziecko   Utwórz/zastąp   o  ID=17  rodzica   dziecko  rodzica   o  ID=132   o  ID=132   nadając  mu   ID=17  

Utwórz  pod-­‐ dziecko  …  

Usuń  dziecko   ID=17  z  rodzica   o  ID=132  

http://example.com?parent=132&child=17  

j.w.  

j.w.  

j.w.  

j.w.  

http://example.com/parents/132?child=17  

j.w  

j.w  

j.w  

j.w  

60

¡  http://jersey.java.net/     ¡  Biblioteka  Java  dla  RESTful  Web  services  

61

¡  Przykładowa  struktura  pakietów  projektu  

62

¡  Klasa  oferująca  interfejs  RESTful  

@Path("/voting") public class VotingRest { @POST @Path("/vote/{userId}/{objectId}/{value}") @Produces(MediaType.APPLICATION_JSON) public JSONObject vote(@PathParam(”userId") String userId, @PathParam("objectId") String objectId, 
 @PathParam(”value") int value) throws JSONException { // pominięty kod odpowiedzialny za znalezienie obiektu i zarejestrowanie głosu JSONObject result = new JSONObject(); result.put(”vote”, object.getVote()); return result; } @GET @Path("/getVote") @Produces(MediaType.APPLICATION_JSON) public JSONObject getVote(@QueryParam("objectId") String objectId) throws JSONException { // pominięty kod odpowiedzialny za znalezienie obiektu JSONObject result = new JSONObject(); result.put(”vote”, object.getVote()); return result; } }

63

¡  Definicja  servletu  Jersey  w  web.xml   Jersey com.sun.jersey.spi.container.servlet.ServletContainer com.sun.jersey.config.property.packages pl.lodz.p.kis.ksoir.rest Jersey /rest/*

64

¡  Kod  JS  zwracający  głosy  na  obiekt  ( jQuery)   function getVote(objectId) { var vote = null; var restUrl = "http://my.host/voting-ws/rest/voting/getVote?objectId=" + escape(objectId); $.ajax({ url: restUrl, async: false, success: function(voteJsonString, textStatus, jqXHR) { vote = JSON.parse(voteJsonString); } }); return vote; }

65