[WAI] egzamin opracowanie pytań

• wyjaśnij różnice pomiędzy ciasteczkami a obiektem sesji
  
  SESJE
• PHP udostępnia mechanizm śledzenia sesji zwany popularnie po prostu sesjami. 
• To, w jaki sposób przechowywane są dane sesji (czy po stronie serwera, czy w przeglądarce), uzależnione jest od konfiguracji PHP. Zwykle jednak pozostawia się konfigurację...
• Sesja może zostać uruchomiona na trzy sposoby: 
• automatycznie – jeżeli opcja session.auto_start w konfiguracji jest ustawiona na jeden; 
• jawnie – poprzez wywołanie funkcji session_start() ;
• niejawnie – poprzez wywołanie funkcji session_register() ;
  
  materiały od Czarnula:
• Sesja
• Sesja jest obiektem klasy HttpSession. Może zostać pobrana np. poprzez wywołanie odpowiedniej metody na obiekcie żądania: request.getSession().
• Podstawowe operacje na obiekcie sesji:
• Object getAttribute(String name) – pobranie obiektu z sesji,
• void setAttribute(String name, Object obj) – dodanie obiektu do sesji,
• void invalidate() - zniszczenie obiektu sesji,
• void removeAttribute(String name) – usunięcie obiektu z sesji.

           CIASTECZKA

• Ciasteczka (ang. cookies) to mechanizm pozwalający na zapamiętywanie po stronie klienta (przez przeglądarkę) danych wysłanych przez stronę WWW.
•  Ciasteczka charakteryzują się różnym czasem trwałości — można tworzyć ciasteczka, których ważność wygasa...

z netu:

1. You don't need login/logout mechanisms in order to have sessions.
2. In java servlets, HTTP sessions are tracked using two mechanisms, HTTP cookie (the most commonly used) or URL rewriting (to support browser without cookies or with disabled cookies). Using only cookies is simple, you don't have to do anything special. For URL re-writing, you need to modify all URLs pointing back to your servlets/filters.
3. Each time you call request.getSession(true), the HttpRequest object will be inspected in order to find a session ID encoded either in a cookie OR/AND in the URL path parameter (what's following a semi-colon). If the session ID cannot be found, a new session will be created by the servlet container (i.e. the server).
4. The session ID is added to the response as a Cookie. If you want to support URL re-writing also, the links in your HTML documents should be modified using the response.encodeURL() method. Calling request.getSession(false) or simply request.getSession() will return null in the event the session ID is not found or the session ID refers to an invalid session.
5. There is a single HTTP session by visit, as Java session cookies are not stored permanently in the browser. So sessions object are not shared between clients. Each user has his own private session.
6. Sessions are destroyed automatically if not used for a given time. The time-out value can be configured in the web.xml file.
7. A given session can be explicitly invalidated using the invalidate() method.
8. When people are talking about JSESSIONID, they are referring to the standard name of the HTTP cookie used to do session-tracking in Java.

The servlet container (for example Tomcat) takes care of this utilizing its JSESSIONID.
The story goes like this :

1. User first logs onto website.
2. Servlet container sets a COOKIE on the user's browser, storing a UNIQUE jsessionId.
3. Every time the user hits the website, the JSESSIONID cookie is sent back.
4. The servlet container uses this to keep track of who is who.
5. Likewise, this is how it keeps track of the separation of data. Every user has their own bucket of objects uniquely identified by the JSESSIONID.

[Z THINKING IN ENTERPRISE JAVA]

Handling sessions with servlets

HTTP is a “sessionless” protocol, so you cannot tell from one server hit to another if you’ve got the same person repeatedly querying your site, or if it is a completely different person. A great deal of effort has gone into mechanisms that will allow Web developers to track sessions. Companies could not do e-commerce without keeping track of a client and the items they have put into their shopping cart, for example.

There are several methods of session tracking, but the most common method is with persistent “cookies,” which are an integral part of the Internet standards. The HTTP Working Group of the Internet Engineering Task Force has written cookies into the official standard in RFC 2109 (ds.internic.net/rfc/rfc2109.txt or check www.cookiecentral.com).

A cookie is nothing more than a small piece of information sent by a Web server to a browser. The browser stores the cookie on the local disk, and whenever another call is made to the URL that the cookie is associated with, the cookie is quietly sent along with the call, thus providing the desired information back to that server (generally, providing some way that the server can be told that it’s you calling). Clients can, however, turn off the browser’s ability to accept cookies. If your site must track a client who has turned off cookies, then another method of session tracking (URL rewriting or hidden form fields) must be incorporated by hand, since the session tracking capabilities built into the servlet API are designed around cookies.

The Cookie class

The servlet API (version 2.0 and up) provides the Cookie class. This class incorporates all the HTTP header details and allows the setting of various cookie attributes. Using the cookie is simply a matter of adding it to the response object. The constructor takes a cookie name as the first argument and a value as the second. Cookies are added to the response object before you send any content.

Cookie oreo = new Cookie("TIJava", "2002");

res.addCookie(oreo);

Cookies are recovered by calling the getCookies( ) method of the HttpServletRequest object, which returns an array of cookie objects.

Cookie[] cookies = req.getCookies();

You can then call getValue( ) for each cookie, to produce a String containing the cookie contents. In the above example, getValue("TIJava") will produce a String containing “2002.”

The Session class

A session is one or more page requests by a client to a Web site during a defined period of time. If you buy groceries online, for example, you want a session to be confined to the period from when you first add an item to “my shopping cart” to the point where you check out. Each item you add to the shopping cart will result in a new HTTP connection, which has no knowledge of previous connections or items in the shopping cart. To compensate for this lack of information, the mechanics supplied by the cookie specification allow your servlet to perform session tracking.

A servlet Session object lives on the server side of the communication channel; its goal is to capture useful data about this client as the client moves through and interacts with your Web site. This data may be pertinent for the present session, such as items in the shopping cart, or it may be data such as authentication information that was entered when the client first entered your Web site, and which should not have to be reentered during a particular set of transactions.

The Session class of the servlet API uses the Cookie class to do its work. However, all the Session object needs is some kind of unique identifier stored on the client and passed to the server. Web sites may also use the other types of session tracking but these mechanisms will be more difficult to implement as they are not encapsulated into the servlet API (that is, you must write them by hand to deal with the situation when the client has disabled cookies).

Inside the service( ) method, getSession( ) is called for the request object, which returns the Session object associated with this request. The Session object does not travel across the network, but instead it lives on the server and is associated with a client and its requests.

getSession( ) comes in two versions: no parameter, as used here, and getSession(boolean). getSession(true) is equivalent to getSession( ). The only reason for the boolean is to state whether you want the session object created if it is not found. getSession(true) is the most likely call, hence getSession( ).

The Session object, if it is not new, will give us details about the client from previous visits. If the Session object is new then the program will start to gather information about this client’s activities on this visit. Capturing this client information is done through the setAttribute( ) and getAttribute( ) methods of the session object.

java.lang.Object getAttribute(java.lang.String)

void setAttribute(java.lang.String name,

java.lang.Object value)

The Session object uses a simple name-value pairing for loading information. The name is a String, and the value can be any object derived from java.lang.Object. SessionPeek keeps track of how many times the client has been back during this session. This is done with an Integer object named sesspeek.cntr. If the name is not found an Integer is created with value of one, otherwise an Integer is created with the incremented value of the previously held Integer. The new Integer is placed into the Session object. If you use same key in a setAttribute( ) call, then the new object overwrites the old one. The incremented counter is used to display the number of times that the client has visited during this session.

getAttributeNames( ) is related to getAttribute( ) and setAttribute( ); it returns an enumeration of the names of the objects that are bound to the Session object. A while loop in SessionPeek shows this method in action.

You may wonder how long a Session object hangs around. The answer depends on the servlet container you are using; they usually default to 30 minutes (1800 seconds), which is what you should see from the ServletPeek call to getMaxInactiveInterval( ). Tests seem to produce mixed results between servlet containers. Sometimes the Session object can hang around overnight, but I have never seen a case where the Session object disappears in less than the time specified by the inactive interval. You can try this by setting the inactive interval with setMaxInactiveInterval( ) to 5 seconds and see if your Session object hangs around or if it is cleaned up at the appropriate time. This may be an attribute you will want to investigate while choosing a servlet container. 

•  Wyjaśnij metody podtrzymania sesji w komunikacji w Internecie z wykorzystaniem HTTP. (5pkt)

         Istnieją 3 sposoby na utrzymanie sesji

• Cookies 
• Ukryte pola formularza 
• Przepisywanie URL’a  
• [Serwlety]
• Będą używać  cookies jeśli to możliwe
• Będą przepisywać  URL jeśli nie ma Cookiem
• Klient wysyła do serwera żądanie. 
• Gdy sesja się rozpoczyna zostaje przypisane ID. 
• Dane sesji zapisywane są w pamięci, pliku lub BD. 
• Serwer wysyła odpowiedź a z nią id sesji (np. set cookie). 
• Przy kolejnych żądaniach serwer odczytuje ciasteczko. 
• Ciasteczko jest usuwane, jeśli upłynął czas jego ważności, bądź po wylogowaniu użytkownika.
   
• Jeśli nie ma włączonych cookies, to serwer przypisuje id sesji do adresu URL

33) Wyjaśnij znaczenie mechanizmu sesji. Podaj podstawowe mechanizmy utrzymywania sesji.

Sesja jest potrzebna, gdy serwer chce śledzić poczynania użytkownika (tzn. jego kolejne żądania):

- Utrzymywanie koszyka zakupów użytkownika

- Zapisywanie informacji o autoryzacji dostępu

-- Sesje są problemem dla serwerów HTTP 

-- Brak mechanizmu sesji HTTP (bezstanowość)

-- Współdzielenie sesji przez wszystkie przeglądarki (jednego typu)

Utrzymywanie sesji.

- Cookies

- Ukryte pola formularza 

- Przepisywanie URL’a 

- Serwlety

-- Będą używać  cookies jeśli to możliwe

-- Będą przepisywać  URL jeśli nie ma cookies 

Każda sesja ma unikalne ID. Gdy sesja się rozpoczyna zostaje przypisane ID. Każde następne „podzapytanie” musi przesyłać ID (przez cookie lub URL)

26) Jaka jest różnica w wywołaniu metod GET i POST ? Podaj przykłady użycia poszczególnych metod.

POST:

Przesłanie danych do zasobu o danym URI, dane w treści żądania

wysyła wszystkie dane z formularza przy pomocy nagłówków http

można przesyłać nieograniczoną ilość informacji

możliwość wysyłania plików na serwer

używany głównie do przesyłania danych z formularza html do skryptu cgi

GET:

Uzyskanie zasobu o danym URI

przesyła informacje do serwera doklejając je do adresu

nadaje się tylko do przesyłania małej ilości informacji, gdyż długość adresów jest ograniczona

• Wyjaśnij jak zabezpieczyć warstwę prezentacji aplikacji internetowej.
• sprawdzenie parametrów stron
• sprawdzenie parametrów w kontekście sekwencji wywołań (bardzo wiele możliwości)
• weryfikacja parametrów w kontekście wcześniej złożonego żądania
• usuwanie niebezpiecznych znaków z pól tekstowych itp. – możliwość np. przedłużenia zapytania SQL lub polecenia w Shellu etc.

• Podaj znane Ci standardy bezpieczeństwa wykorzystywane przez aplikacje internetowe.
• Uwierzytelnianie i autoryzacja w oparciu o serwery i aplikacje
• • Autentyfikacja jest procesem identyfikacji użytkownika w systemie komputerowym, a następnie weryfikacji jego tożsamości. 
  • Autoryzacja dotyczy nadania użytkownikowi określonych uprawnień.
• HTPPS
• HTTP-AUTH
• HTTP Basic Authentication:
• Mechanizm ten umożliwia wymuszenie zalogowania się przez klienta na serwerze poprzez podanie loginu użytkownika oraz hasła. 
• Niestety, login i hasła nie są szyfrowane w   sposób   uniemożliwiający   ich   odczytanie.   
• Mechanizm   ten   pozwala   jednak   na identyfikację   użytkownika   przy   założeniu,   iż   różni   użytkownicy   dysponują   różnymi identyfikatorami użytkownika w postaci ciągu znaków login.
• Ww.   sposób   wymaga   konfiguracji   serwera   w   postaci   określenia   użytkowników, którzy mogą się do systemu logować, a w szczególności:
• Login,   hasło   oraz   rolę   użytkownika   w   postaci   linii   w   pliku   /home/student/apache-tomcat­5.5.28/conf/tomcat­users.xml:

            <?xml version='1.0' encoding='utf­8'?> 

                 <tomcat­users> 

                   <role rolename="tomcat"/>   

                   <role rolename="role1"/> 

                   <role rolename="runtaskuser"/> 

                   <user username="tomcat" password="tomcat" roles="tomcat"/>

                   <user username="both" password="tomcat" roles="tomcat,role1"/>      

                   <user username="role1" password="tomcat" roles="role1"/> 

                   <user username="runtaskuser" password="uio9" roles="runtaskuser"/> 

                  </tomcat­users> 

• Zdefiniowano  użytkownika runtaskuser, określono  hasło  oraz  rolę, do której referencja występuje z kolei w pliku katalogu systemu AXIS tj.:
• /home/student/apache­tomcat­5.5.28/webapps/axis/WEB­INF/web.xml
• uwierzytelnianie na poziomie aplikacji
• zarządzanie userami/rolami/uprawnieniami

23) Standardy bezpieczeństwa wykorzystywane przez aplikacje internetowe

- połączenia SSL/TLS (Secure Socket Layer/Transport Layer Security) – poufność, uwierzytelnianie danych

- uwierzytelnianie SSH

- certyfikaty w przeglądarkach

- LDAP - wykorzystywany w adresacji sieci Internet/Intranet w celu zapewnienia niezawodności, skalowalności i bezpieczeństwa danych

- zapytania OCSP (Online Certificate Status Protocol) o status certyfikatu i odpowiedzi (tokenu)

- Kerberos - protokół uwierzytelniania i autoryzacji w sieci komputerowej z wykorzystaniem Centrum Dystrybucji Kluczy

- szyfrowanie odwołań do linków

- wygaszanie sesji

- blokowanie uwierzytelniania

- logowanie do serwisów przy pomocy haseł jednorazowych

• wyjaśnij wykorzystanie protokołu http (zalety)
• komunikacja typu request-response
• serwer wykorzystuje metody doGet, doPost
• możliwość odczytu parametrów, generowania dynamicznej treści w odpowiedzi
• obiekt sesji
• Cookies
• możliwość instalowania filtrów
• sposób przekazywania parametrów w metodzie GET, POST  (zabezpieczenie serwletów, serwisu przed podmiana parametrów, np. wcześniejsze żądanie klienta zostaje zapisane do bazy, później weryfikacja – błąd gdy ponownie dane nieprawdziwe)
• ukrywanie parametrów, url stron
• nagłówki, ciało metody
• parametry, które serwet może poznać – identyfikacja komputera użytkownika, itp

• HTTP 1.0. i HTTP 1.1.
• HTTP to protokół sieci WWW (warstwa aplikacji), umożliwiający publikowanie info.
• Protokół HTTP udostępnia znormalizowany sposób komunikowania się kompów ze sobą.
• Określa formę żądań klienta dotyczących danych oraz formę odpowiedzi serwera na te żądania.  
• Jest protokołem typu klient/serwer. 
• Nagłówek z dokładnie określonym formatem pierwszej linii, opcjonalny nagłówek. protokół bezstanowy

Dodatkowe cechy w HTTP 1.1:

• zwiększa wydajność komunikacji między klientem a serwerem dzięki ciągłemu utrzymywaniu połączenia i tworzeniu kanałów wirtualnych
• możliwość przesyłania większej liczby obiektów podczas jednego połączenia TCP/IP
• możliwość używania dłuższych, bardziej efektywnych pakietów
• zarządzanie pamięcią podręczną (cache) przeglądarki 
• zaostrzone wymagania w odniesieniu do sposobu implementacji
• przetwarzanie potokowe
• w ramach 1 połączenia może wystąpić 1 lub więcej sekwencji żądanie-odp

Miejsca wykonywania

Aplety- klient

aplikacja kliencka - klient

CGI- serwer

javascript- klient

JSP- serwer (Web Container)

PHP- serwer

serwlet- serwer

SQL-  serwer BD

CSS- klient

7) wyjaśnij etapy wytwarzania klienta i wywołania usługi sieciowej (bazując na pliku a wsdl). Wyjaśnij co opisuje wsdl 



Język opisuje protokoły i formaty używane przez Web services. Opisy WSDL mogą być umieszczane w rejestrze UDDI - kombinacja WSDL i UDDI ma się przyczynić do promocji rozwiązań Web services w światowym Internecie.
WSDL wykorzystuje język XML do opisu punktów dostępu do Web Services. Język WSDL definuje zestaw kilku struktur XML pozwalających na pełny opis usług (struktury danych wymienianych z usługą, sposób połączenia z usługą [najczęściej HTTP]).


WSDL jest to język służący do opisu interfejsu WS za pomocą XML. Służy on do:
- opisu punktów dostępu do usług sieciowych
- definiuje struktury danych wymienianych z usługą
- opisu sposobu połączenia z usługą (najczęściej HTML)
Definiuje on kilka struktur XML pozwalających na pełny opis usług.

• message
• type
• portType
• port
• binding
• service

8) wyjaśnij co to jest rejestr uddi, jakie informacje przechowuje (wymień 4 podstawowe elementy opisu w uddi – podaj nazwy i znaczenie).


inicjatywa przemysłu informatycznego mająca na celu utworzenie uniwersalnego rejestru biznesowego Web services. UDDI została pierwotnie opracowana przez Ariba, IBM, Microsoft i inne firmy. UDDI jest to baza danych w której rejestrowane są dostępne komponenty, które mogą być przeszukiwane przez twórców aplikacji, klientów bądź przez same aplikacje.
UDDI pozwoli oprogramowaniu automatycznie wykrywać i integrować Web services w sieci Internet. Przeglądarka UDDI umożliwi także przeglądanie użytkownikom informacji o rejestrze, który jest siecią serwerów internetowych podobnym do Domain Name System (DNS).
UDDI zawiera tzw:

• businessEntity
• businessService
• bindingTemplate
• tModel

/*
- white pages, czyli adresy i kontakty;  podstawowe dane o dostawcy usługi, obejmujące nazwę firmy, adres, identyfikator(np. nip)


- yellow pages, czyli klasyfikacje przemysłowe; lokalizacja usługi w taksonomiach kategoryzacyjnych


- green pages (opisy usług). Green pages zawierają wersję XML, typ szyfrowania i Document Type Definition (DTD) standardu; techniczny opis usługi i jej semantyki, często tez wskaźnik do pliku wsdl
*/

41) Opisz ideę stosowania Web-services’ów. Wymień podstawowe komponenty stosowane w tej technologii.

Web service jest aplikacją działającą na serwerze, do której można uzyskać dostęp z wykorzystaniem technologii XML. Web services pozwala na zdalne wywołanie procedury na komputerze odległym włączonym do Internetu.

9) wyjaśnij jak zabezpieczysz dostęp do aplikacji internetowej wykorzystującej serwlty/strony jsp w warstwie prezentacji


- sprawdzanie parametrów stron
- sprawdzanie parametrów w kontekście wywołań
- weryfikacja parametrów w kontekście wcześniej złożonego żądania
- usuwanie niebezpiecznych znaków z pól tekstowych .- możliwość np. przedłużenia zapytania SQL lub polecenia w Stellu etc.
- autoryzacja użytkowników w rożnych warstwach systemu
- przesyłanie danych bezpiecznymi kanałami systemu
- unikanie w projektowaniu i implementacji aplikacji wrażliwych na atak
- przestrzeganie procedur bezpieczeństwa przez wszystkich użytkowników systemu
- https
- autentyfikacja i autoryzacja użytkowników w poszczególnych warstwach
systemu,
- przesył danych oraz wrażliwych informacji bezpiecznymi kanałami
systemu,


10) wyjaśnij co to jest architektura wielowarstwowa i podaj przykład technologii pozwalającej na implementacje.


Architektura wielowarstwowa polega na rozdzieleniu interfejsu użytkownika, przetwarzania i składowania danych na kilka osobnych warstw, które mogą być oddzielnie rozwijane i aktualizowane, co ułatwia ich utrzymanie i nie wpływa negatywnie na funkcjonowanie pozostałych warstw. 


Przykład technologii: php, serwlety, strony jsp


Wyróżnione i wydzielone warstwy: użytkownika, prezentacji, logiki biznesowej,systemów baz danych np.. przeglądarka internetowa/Toccat/MySql Łatwa do wykorzystania technologie jak PHP , serwety, strony JSP Komponentowy rozwój oprogramowania np.J2EE, Microsoft.NET

17) Aplikacja wielowarstwowa

w ramach warstwy serwera kilka pod-warstw, zarządzanych względnie niezależnie od oprogramowania (Serwer Web- serwer aplikacji- serwer bd –bd)

•Model klient-serwer- arch. 3-warstw: w.klienta (odpowiada za interfejs usera), w.serwera (logikę przetwarzania), w.danych (serwer BD) 

•Środkowa warstwa może składać się z wielu warstw, co jest określane jako architektura wielowarstwowa. 

• Synchronizacja w dostępie do współdzielonych danych
  
     [NOTATKI Z "THINKING IN JAVA"]:
• metoda szeregowania dostępu do zasobów wspólnych
• w danej chwili tylko jedno zadanie może mieć dostęp do wspólnego zasobu
• realizacja poprzez umieszczenie fragmentu kodu wewnątrz klauzuli blokującej, dzięki której w danej chwili tylko jedno zadanie może realizować dany kod
• ponieważ klauzula ta powoduje wzajemne wykluczanie zadań z wykonania chronionego nią kodu określana jest często jako (mutual exclusion) "mutex"
• priorytety wątków ustawia się poprzez metody yield() i setPriority();
• Java posiada wbudowany mechanizm zapobiegania kolizją podczas dostępu do zasobów współdzielonych - słowo kluczowe synchronized
• gdy wątek wyraża chęć wykonania fragmentu kodu chronionego słowem kluczowym synchronized - mechanizm zapezpieczający:
1. sprawdza czy blokada jest wolna (czy inny wątek nie wykonuje kodu)
2. zakłada blokadę
3. wykonuje kod
4. zwalnia blokadę
• Aby kontrolować dostęp do zasobu współdzielonego, należy 
• najpierw umieścić go wewnątrz obiektu
• następnie należy synchronizować każdą metodę korzystającą z tego zasobu

 [Z "THINKING IN ENTERPRISE JAVA"]:

Servlets and multithreading

The servlet container has a pool of threads that it will dispatch to handle client requests. It is quite likely that two clients arriving at the same time could be processing through your service( ) at the same time. Therefore the service( ) method must written in a thread-safe manner. Any access to common resources (files, databases) will need to be guarded by using the synchronized keyword.

The following simple example puts a synchronized clause around the thread’s sleep( ) method. This will block all other threads until the allotted time (five seconds) is all used up. When testing this you should start several browser instances and hit this servlet as quickly as possible in each one—you’ll see that each one has to wait until its turn comes up.

//: c15:servlets:ThreadServlet.java

// {Depends: j2ee.jar}

import javax.servlet.*;

import javax.servlet.http.*;

import java.io.*;

public class ThreadServlet extends HttpServlet {

int i;

public void service(HttpServletRequest req,

HttpServletResponse res) throws IOException {

res.setContentType("text/html");

PrintWriter out = res.getWriter();

synchronized(this) {

try {

Thread.currentThread().sleep(5000);

} catch(InterruptedException e) {

System.err.println("Interrupted");

}

}

out.print("<h1>Finished " + i++ + "</h1>");

out.close();

}

} ///:~

It is also possible to synchronize the entire servlet by putting the synchronized keyword in front of the service( ) method. In fact, the only reason to use the synchronized clause instead is if the critical section is in an execution path that might not get executed. In that case, you might as well avoid the overhead of synchronizing every time by using a synchronized clause. Otherwise, all the threads will have to wait anyway so you might as well synchronize the whole method. 

              KOMPONENTY JavaBean I SYNCHRONIZACJA

• wszystkie publiczne metody komponentu powinny być synchronizowane
• małych metod (tak małych, że w trakcie ich wykonania nie może być zmieniony stan obiektu; atomowe) w ostateczności nie trzeba synchronizować

            [POZOSTAŁE NOTATKI ]:

• Obsługa każdego żądania przekazanego do serwletu odbywa się w ramach tzw. lekkiego wątku, co oznacza że własności klasy serwletu wraz z ich aktualnymi wartościami są współdzielone przez aktywne wątki. 
• Współdzielenie zasobów często wymaga wprowadzenia własnych mechanizmów synchronizacji. Można tego uniknąć ustalając, że serwlet implementuje SingleThreadModel 
• dostęp wielu komponentów do obiektów związanych z kontekstem aplikacji do obiektów sesyjnych 
• dostęp wielu wątków do obiektów pojedynczego komponentu
• dostęp do obiektów statycznie zadeklarowanych

34) Opisz cel stosowania i podaj implementację wzorca projektowego Singleton.

Cele stosowania:

- Często w aplikacji istnieje potrzeba stworzenia klasy, która posiadałaby wyłącznie jedną instancję. 

- Zwykle związane to jest z zapewnieniem większej wydajności aplikacji, np. przy dostępie do bazy danych, gdzie każde łączenie się z bazą jest dla aplikacji kosztowne, bo wymaga czasochłonnego uwierzytelnienia i autoryzacji. 

- W tym przypadku sensowniej jest stworzyć jeden obiekt przechowujący sesję połączenia i wykorzystać go do przesłania wielu zapytań.

- Należy zastosować wzorzec singletonu

public class Singleton { 

private static Singleton instance = null;

public static synchronized Singleton getInstance() { if (instance == null) instance = new Singleton();

return instance; } 

private Singleton() { return getInstance(); }

} 

31) Na czym polega blokada typu two-phase commit ? Dlaczego stosuje się ją w aplikacjach internetowych.

Algorytm dwufazowy (two phase commit): 

- Przed rozpoczęciem pierwszej operacji transakcja zakłada blokady (shared - do czytania i exclusive - do pisania) na wszystkie zasoby, z których będzie korzystać - faza wstępująca 

- Po zakończeniu wszystkich operacji transakcja zdejmuje wcześniej założone blokady i kończy się - faza zstępująca 

Nazwa two phase commit jest szerzej stosowana dla systemów transakcji rozproszonych, gdzie mamy zbiór transakcji, który do zakończenia się sukcesem (commit) wymaga, aby wszystkie transakcje zostały zatwierdzone. Jeżeli choć jedna z nich zawiedzie, wszystkie pozostałe muszą się cofnąć (rollback). Stąd commit ma dwie fazy: wstępną (symulacyjną) i końcową (właściwą).

Blokadę tą stosuje się w celu uniknięcia takich sytuacji jak: 1. Zapis - zapis. Utrata aktualizacji. 2. Zapis - odczyt. Odczyt niewłaściwy. 3. Odczyt - zapis. Odczyt niepowtarzalny. 

32) Podaj schemat wydobywania informacji przez serwlet z bazy danych. Podaj sposoby ładowania sterownika dostępu do bazy w serwlecie.

- Ładowanie sterownika JDBC i nawiązanie połączenia z bazą danych

- Przygotowanie zapytań SQL

- Pętla przetwarzania:

-- Ustawienie wartości dla parametrów wejściowych 

-- Wykonanie zapytania SQL

-- Przetwarzanie rezultatów

- Zamknięcie zbioru rezultatów

- Zamknięcie zapytania

- Zamknięcie połączenia

Przykład:

Class.forName("com.mysql.jdbc.Driver");

Connection con = DriverManager.getConnection("jdbc:mysql://localhost/test", "testuser", "testpass");

13) Opisz warstwy w technologii J2EE oraz komponenty działające w każdej z nich.(7pkt)

Warstwy J2EE i komponenty

• W.kliencka - najczęściej stosowane rozwiązania to tworzenie tzw. cienkiego klienta - umieszczanie wyłącznie mechanizmów związanych z jego wyświetlaniem i obsługą operacji dokonywanych na interfejsie przez usera. El: przeglądarka, kontener aplikacji klienckiej
• W.serwera - odpowiada za obsługę logiki biznesowej systemu. Zgłoszenia usera są obsługiwane i przetwarzane za pomocą komponentów biznesowych zbudowanych w oparciu o technologię EJB. El: (Web kontener) Serwlety, Strony JSP  (do prezentacji) (Biblioteki Znaczników– El JSP w formacie XML, Java Standard Tag Library (JSTL), Java Server Faces (JSF)), Java Beans (Enterprise Bean w kontenerze EJB.Używane jako obiekty z wartościami, przekazujące dane do JSP), Deskryptor Web Deployment (/web-inf/web.xml)
• W.danych - odpowiada za realizację mechanizmu trwałości. Obiekty biznesowe są utrwalane z wykorzystaniem np. relacyjnej bazy danych.

Serwlety

Strony JSP  (do prezentacji)

Biblioteki Znaczników (Tag Libraries)  – Elementy JSP w formacie XML 

Java Standard Tag Library (JSTL)

Java Server Faces (JSF)

Java Beans (Używane jako obiekty z wartościami, przekazujące dane do JSP)

Deskryptor Web Deployment 

/web-inf/web.xml

14) Wyjaśnij sekwencje wywołań usług prowadzących do znalezienia i wywołania usługi sieciowej przez klienta i protokoły wykorzystywane do wywołania.(6pkt)

19) Sekwencja wywołań usług

Uruchomienie usługi sieciowej: utworzenie usługi oraz zdefiniowanie interfejsów i metod jej wywołania,opublikowanie usługi w internetowym lub intranetowym repozytorium (serwery UDDI oraz API),

stworzenie możliwości odnalezienia jej przez potencjalnych odbiorców (UDDI- Find, Get...Detail),

zdalne wywołanie przez klienta. 

User-wyszukuje serwis-> rejestr UDDI- wskazuje na opis/serwis-> WSDL- opisuje serwis-> Web Service<- SOAP, komunikacja XML-> user 

•  SOA – wołanie zdalnych usług z wykorzystaniem jasno zdefiniowanych standardów: WSDL, SOAP, XML

Web Services nie są blokowane przez firewalle

UDDI jako rejestr informacyjny

szereg standardów związanych z integracją usług

usługa może wywoływać inne usługi, budowa złożonych scenariuszy składających się z usług – workflows

przenośność

Rozproszone systemy obiektowe - klient serwer na bazie obiektów usługi zdefiniowane i wspierane przez środowisko rozproszone/ obiekty np. CORBA (blokowanie przez firewalle)

SOAP 

protokół wywoływania zdalnego dostępu do obiektów, wykorzystujący XML do kodowania wywołań i najczęściej HTTP do ich przenoszenia, możliwe jest wykorzystanie innych protokołów do transportu danych. Dokument SOAP składa się z: + koperty która określa szkielet opisujący, co znajduje się w komunikacie i jak go przetwarzać,

+ zbioru reguł kodujących potrzebnych do rozszyfrowania typów danych zdefiniowanych wew aplikacji,

+ reguł dotyczących wywoływania zdalnych metod i odczytu odpowiedzi.

• WSDL

oparty na XML język do definiowania usług sieciowych. Opisuje protokoły i formaty używane przez usługi sieciowe. Opisy WSDL mogą być umieszczane w rejestrze UDDI. Dokument WSDL określa usługi, jako zestawy punktów końcowych, inaczej portów. Ich abstrakcyjna definicja jest oddzielona od konkretnych wiązań. Dzięki temu zapewniona zostaje możliwość wielokrotnego używania abstrakcyjnych definicji: wiadomości – abstrakcyjnego opisu wymienianych danych i typów portów – abstrakcyjnych zestawów operacji. Konkretne połączenie typu portu z protokołem i formatem danych tworzy wiązanie. Port jest określony jako adres sieciowy oraz wiązanie. Zestaw portów z kolei tworzy usługę.

El: wsdl:message, type, portType, port, binding, service

• UDDI

to katalog, który umożliwia publikowanie i wyszukiwanie usług sieciowych. Wprowadza możliwość podawania dokładnych info – o dostawcy serwisów i udostępnianych usługach (opisy, interfejsy, wiązania). Może przechowywać info o dowolnym typie serwisów. W ich ramach mogą być udostępniane odnośniki służące do pobrania aplikacji, pełniących rolę klientów dla wskazanych usług oraz operujących za pomocą specyficznych protokołów komunikacyjnych. Struktura katalogu: Business Entity, Business Service, Binding Templates, Service Types (tModel)

• Web Services

to standardowy interfejs, który pozwala jednej aplikacji programowo odkryć, zinterpretować i wykorzystać usługi oferowane przez inne platformy aplikacyjne bądź sys operacyjne, w sposób niezależny od wykorzystywanego przez nie j. programowania

16) Wyjasnij odwzorowanie WSDL na UDDI i cel odwzorowania.(5pkt)

W celu uproszczenia dystrybucji dokumentów WSDL i semantyki komponentów usługowych Web Services zaproponowano, aby dostępne komponenty były rejestrowane w specjalizowanej bazie danych, która może być następnie przeszukiwana przez twórców aplikacji-klientów lub przez same aplikacje-klientów z zamiarem odkrycia potrzebnych komponentów. Opracowaną specyfikację takiej bazy danych nazwano UDDI. Bazy danych UDDI deklarują dostępne usługi posługując się trzema poziomami opisu:

- White Pages: podstawowe dane kontaktowe o dostawcy usługi, obejmujące nazwę firmy, adres, identyfikator

- Yellow Pages: lokalizacja usługi w taksonomiach kategoryzacyjnych

- Green Pages: techniczny opis usługi i jej semantyki, często też wskaźnik do wpisu WSDL

18) Zaimplementowanie sesji dla usług sieciowych

• po stronie serwera dodajemy do klasy serwisu obsługę sesji poprzez:
• wydobycie obiektu kontekstu serwletu:

MessageContext mc = wsContext.getMessageContext();

HttpSession session = ((javax.servlet.http.HttpServletRequest)mc.get(MessageContext.SERVLET_REQUEST)).getSession();

• po stronie klienta uaktywniamy opcję wysyłania żądania przy użyciu podtrzymania sesji - używamy do tego przechwyconego kontekstu żądania z odpowiednią opcją:

Hello proxy = new HelloService().getHelloPort();
((BindingProvider)proxy).getRequestContext().put(BindingProvider.SESSION_MAINTAIN_PROPERTY,true);

-Pozyskanie nowej sesji (z obiektu żądania) :

HttpSession s=request.getSession(true);

-Zapamiętanie obiektów w czasie sesji:

s.putValue("item-name",myobject);

-Pozyskanie obiektów:

s.getValue("item-name");

- Można nasłuchiwać czy obiekty są dodane lub usunięte z sesji – listener’y

20) Modele przetwarzania w Internecie

Klient – serwer (SMTP, FTP, HTTP)

Klient - pośrednik – serwer (DNS, UDD)

Peer-to-peer (emule, IRC, Skype)

Klient – serwer:

Serwer usługi czeka na nawiązanie połączenia przez klienta

Wiele klientów może korzystać z usługi jednocześnie

Komunikacja w ramach usługi opiera się o powszechnie znany, standardowy protokół

Do usługi przypisany jest domyślny port, lub zestaw portów, na których nasłuchuje serwer

24) Wyjaśnij pojęcie modelu „głębokiego” Internetu. W jaki sposób można rozwiązać podstawowe wady tego modelu ?

Tzw. Głęboki Internet albo ukryty Internet zawiera kilkaset razy więcej zasobów niż Internet do powszechnego użytku, widoczny dla zwykłych przeglądarek. Większość tych zasobów stanowią specjalistyczne bazy danych i dokumentów elektronicznych, a także archiwa bardzo cennych materiałów źródłowych i referencyjnych. Zwykłe przeglądarki nie indeksują stron internetowych z tymi materiałami.

Zasoby te utrzymywane są w sieci głównie przez uniwersytety oraz instytucje rządowe 

i międzynarodowe. Odnośniki do tych olbrzymich zasobów są zbierane, kwalifikowane 

i katalogowane przez wyspecjalizowanych redaktorów. Katalogi są często jedyną "bramą", przez którą można dotrzeć do zasobów wielokrotnie większych, niż te dostępne powszechnie.

25) Wymień znane Ci schematy URL. Określ różnice pomiędzy URI, URL i URN.

Schematy URL:

FTP HTTP TELNET NEWS MAILTO FILE

• URI – (Uniform Resource Identificator) jest uogólnioną składnią przeznaczoną do definiowania zasobów w sieci. URI składa się z nazwy schematu i ścieżki dostępu/części specyficznej dla schematu Jest najbardziej ogólnym sposobem adresowania zwierającym w sobie tak klasyczne URLe jak i identyfikatory wiadomości w poczcie.
• Do podstawowych założeń URI (jako specyficznego języka definiowania lokalizacji) należało: 
• rozszerzalność o nowe protokoły 
• kompletność w momencie tworzenia 
• możliwość wydruku/wiernego wyświetlenia na 7bit terminalach 
• URL – (Uniform Resource Lokator) URL składa się z nazwy schematu i części dopełniającej (właściwego adresu). URL składa się ze schematu, nazwy protokołu oraz z części specyficznej dla danego schematu.
• URN - Uniform Resource Name jest projektowany do serwowania trwałych, niezależnych od lokalizacji identyfikatorów obiektów w Sieci i łatwego korelowania takiej pozycji z innymi schematami adresowania. Niestety z powodu uciążliwości potencjalnej realizacji (wymagana by była duża niezależna od lokalizacji baza danych itp.) nie stosowany w praktyce. Jedną z nielicznych istniejących implementacji są NetWords

27) Wymień główne komponenty aplikacji internetowej wykonanej w języku Java. W

odpowiedzi podaj również odpowiedni rysunek

28) Serwlety i strony JSP oferują identyczną funkcjonalność. Jakie są wady i zalety

stosowania każdego z podejść ?

serwlety:

- Zasadniczo: 

-- do wyświetlania dynamicznych stron WWW

-- przetwarzanie formularzy (logika biznesowa)

- Dobrze pracują w środowisku heterogenicznym

-- Niezależne od platformy i OS 

-- Pracują ze wszystkimi głównymi serwerami www

- Łatwa i czysta separacja logiki od prezentacji

- Wydajne i dobrze skalowalne

- Pomaga w komunikacji klient – serwer

- serwlety mogą korzystać ze standardowych klas Javy (z VM), klas wchodzących w skład Servlet API oraz ewentualnie z dodatkowych bibliotek zainstalowanych na serwerze. 

b) jsp

- JSP to technologia przetwarzania wsadowego do użytku w ramach Web Container 

- jest bardzo ściśle powiązana z serwletami. Przy pierwszym uruchomieniu strona JSP tłumaczona jest na klasę Java, która faktycznie jest wyspecjalizowanym serwletem 

Porównanie JSP i Servletów 

Skoro strony JSP są automatycznie tłumaczone na servlety Javy, nie ma różnic w możliwościach stron JSP i servletów. Zarówno jedne jak i drugie są wykonywane na pojedynczej Wirtualnej Maszynie Javy (JVM), eliminując potrzebę, aby serwer Webowy musiał tworzyć nowy proces za każdym razem gdy nadchodzi żądanie strony. Jest to poważna przewaga nad mechanizmami typu skryptów CGI. Główna korzyść z JSP w stosunku do servletów to umożliwienie bardziej przejrzystego podziału pomiędzy prezentacją (wygenerowany HTML) a logiką strony serwera, która określa w jaki sposób jest ,,wypełniana'' strona. Łatwo jest zmienić wygląd strony JSP bez konieczności zmian w kodzie Javy, czy to na stronie JSP czy też w JavaBean.

29) Podaj sposób osadzania witryny opartej o technologię JSP/serwlet na serwerze www. Przedstaw odpowiednią strukturę katalogów i miejsca, gdzie ulokowane są strony html, strony JSP, klasy serwletów, klasy pomocnicze w postaci archiwum, w tym sterowniki JDBC, obrazki i klasy JavaBeans.

*.html, *.jsp, etc. – muszą być widoczne dla przeglądarki użytkownika, zazwyczaj znajdują się we wspólnym katalogu

/WEB-INF/web.xml – plik XML określający servlety i inne komponenty tworzące daną aplikację

/WEB-INF/classes/ - pliki .class Java’y (i powiązane zasoby), włączając klasy servletów i klasy nie-servletów, które nie są połączone w pliki JAR. 

/WEB-INF/lib/ - pliki JAR zawierające pliki class Java’y wymagane przez daną aplikację – np. biblioteki class i sterowniki JDBC.

30) Jakiego rodzaju informacje zawiera deskryptor webowy (plik web.xml) ? Podaj cel jego stosowania.

Deskryptor webowy (Web.xml) zawiera:

- nazwa aplikacji

- definicję i nazwę serwletu 

- parametr inicjalny

- mapowanie zasobów (można tutaj ustalić np. że wywołanie takiego czy innego URL w rzeczywistości odniesie się do serwletu) 

- wzorzec URL 

- konfiguracja sesji 

- czas braku aktywności, po którym sesja przestanie być "ważna”

- Określenie wywołań lokalizacji, które będą obsługiwać określone kody statusu odpowiedzi HTTP

35) Opisz ideę wykorzystania klasy fabryki (factory klas). Podaj przykład takiej klasy w

środowisku języka Java.

FACTORY CLASS

- To jeden z częściej stosowanych wzorców projektowych w projektowaniu obiektowym

- Programista nie tworzy sam obiektów należących do pewnej rodziny klas, zamiast tego istnieje klasa, która potrafi je wygenerować w zależności od potrzeb

- Z klasy bazowej generuje się za pomocą factory class jej różne klasy potomne, różniące się implementacją ale posiadające ten sam interfejs

- Klasa factory sama decyduje, na podstawie pewnych czynników, którą konkretnie implementację zwrócić