public class - Dariusz Pałka Dydaktyka

Tworzenie
Aplikacji
Internetowych
dr Dariusz Pałka
Sun J2EE Tutorial
http://java.sun.com/javaee/5/docs/tutorial/doc/
Rozproszone aplikacje wielowarstwowe
Komponenty J2EE
• Po stronie klienta
– Application clients
– Applets
• Po stronie serwera
– Java Servlet
– JavaServer Pages (JSP)
– Enterprise JavaBeans (EJB)
Klienci J2EE
• Klienci webowi (Web Clients)
• Aplety (Applets)
• Aplikacje klienckie (Application Clients)
Komunikacja z serwerem J2EE
Komponenty webowe
Komponenty biznesowe
Usługi Kontenera
• Kontenery są interfejsami pomiędzy
komponentami i niskopoziomowymi
funkcjami platformy
• Przykłady usług kontenera:
– J2EE security model
– J2EE transaction model
– JNDI lookup services
– J2EE remote connectivity model
Typy kontenerów
Web serwisy
• XML
• SOAP Transport Protocol
• WSDL Standard Format
Warstwa prezentacyjna
JavaServer Faces (JSF)
• JSF to framework do tworzenia interfejsu
użytkownika dla aplikacji webowych
• Podstawowy cel to uproszczenie
najbardziej złożonego i żmudnego
procesu w tworzeniu aplikacji webowych
jakim jest tworzenie UI
Podstawowe składniki JSF
Komponenty (ang. components)
Zdarzenia (ang. events)
Walidatory i konwertery (ang. validators & converters)
Nawigacja (ang. navigation)
Back-end-data integration
JSF
W jaki sposób JSF upraszcza proces
deweloperski
• Bazuje na podejściu skoncentrowanym na
komponentach (component-centric)
• Jest niezależne od klienta (przynajmniej w
znacznej mierze)
• Upraszcza dostęp i zarządzanie warstwą danych z
poziomu webowego interfejsu użytkownika
• Automatycznie zarządza stanem interfejsu
użytkownika pomiędzy wieloma żądaniami i dla
wielu klientów
• Przyjazny dla użytkowników będących na z
różnym poziomem doświadczenia
Java Specification Requests (JSR) #127
• The following 8 design goals represent the focus of this
proposal:
• 1. Create a standard GUI component framework which can
be leveraged by development tools to make it easier for tool
users to both create high quality GUIs and manage the
GUI's connections to application behavior.
• 2. Define a set of simple lightweight Java base classes for
GUI components, component state, and input events.
These classes will address GUI lifecycle issues, notably
managing a component's persistent state for the lifetime of
its page.
• 3. Provide a set of common GUI components, including the
standard HTML form input elements. These components
will be derived from the simple set of base classes (outlined
in #1) that can be used to define new components.
Java Specification Requests (JSR) #127
• 4. Provide a JavaBeans model for dispatching events from
client-side GUI controls to server-side application behavior.
• 5. Define APIs for input validation, including support for
client-side validation.
• 6. Specify a model for internationalization and localization of
the GUI.
• 7. Automatic generation of appropriate output for the target
client, taking into account all available client configuration
data, such as browser version, etc.
• 8. Automatic Generation of output containing required hooks
for supporting accessibility, as defined by Web Acesibility
Initiative (WAI).
Architektura aplikacji JSF
• Aplikacja JSF jest to standardowa, webowa
aplikacja J2EE posiadająca specyficzną
konfigurację
– Wpis w web.xml, który włącza obsługę adresów
URL z określonym wzorcem (np. /faces/*) za
pomocą servletu Face Controller
– Plik konfiguracyjny JSF faces-config.xml
– Katalog WEB-INF zawierający biblioteki Javy:
• jsf-api.jar, jsf-impl.jar (biblioteki JSF)
• commons-beanutils.jar, commonscollections.jar, itp.
• jstl.jar, standard.jar (biblioteki JSTL)
Obsługa żądań (request processing)
w JSF
Faces
Request
Faces
Response
Restore
View
Apply
Request Values
Process
Validations
Render
Response
Invoke
Application
Update Model
Values
Model nawigacji w JSF
• JSF jest zaprojektowany w oparciu o
paradygmat projektowy MVC
– Model – zawiera logikę biznesową lub kod nie
związany z UI
– View (widok) – kod niezbędny do
prezentowania użytkownikowi UI
– Controller (kontroler) – front-end agent
obsługujący żądania użytkownika i
rozdzielający je do odpowiednich widoków
Model nawigacji w JSF
Controller
(Faces Servlet)
View
(JSF Pages)
Model
(Managed Beans)
Reguły nawigacji w faces-config.xml
<navigation-rule>
<display-name>register</display-name>
<from-view-id>/register.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/welcome.jsp</to-view-id>
</navigation-case>
</navigation-rule>
<navigation-rule>
<display-name>register</display-name>
<from-view-id>/register.jsp</from-view-id>
<navigation-case>
<from-outcome>emailRegistered</from-outcome>
<to-view-id>/emailAlreadyRegistered.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Komponenty UI
• Klasa bazowa dla wszystkich komponentów
– UIComponent/UIComponentBase
• Standardowe podklasy klasy UIComponent
– UICommand, UIForm, UIOutput
– UIGraphic, UIInput, UIPanel, UIParameter
– UISelectBoolean, UISelectMany, UISelectOne
• Przykład
– <h:inputText id=”userPasswd”
value=”#{LoginBean.password}” />
Managed Beans
• JSF managed beans
– POJOs przechowujące dane aplikacji i
zarządzane przez kontener
– Muszą być zarejestrowane w face-config.xml
– Można się do nich odwoływać przez JSF EL
np.
<h:outputText value=”#{loginBean.name}” />
– Dostępne zakresy trwałości: none, request,
session, application
Przykład
public class LoginBean {
String name;
String password;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public String getPassword() {
return password;
}
public void setPassword(String password) {
this.password = password;
}
}
Wiązanie UI z Managed Bean
Dostępne komponenty JSF
• MyFaces Trinidad, Tabago, Tomahawk
http://myfaces.apache.org/
• MyFaces Trinidad
http://myfaces.apache.org/trinidad/index.
html
• http://www.jsfcentral.com/
Strona JSF
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f"%><%@taglib
uri="http://java.sun.com/jsf/html" prefix="h"%><%@ page language="java"
contentType="text/html; charset=ISO-8859-2"
pageEncoding="ISO-8859-2"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-2">
<title>Logowanie</title>
</head><body>
<f:view>
<h:form>
<h2>Logowanie</h2>
<h:panelGrid border="1" columns="2">
<h:outputLabel value="login (email):"></h:outputLabel>
<h:outputText value="#{loginBean.name}"></h:outputText>
<h:outputLabel value="hasło:"></h:outputLabel>
<h:inputSecret value="#{loginBean.password}"></h:inputSecret>
</h:panelGrid>
<h:commandButton value="Ok"></h:commandButton>
</h:form>
</f:view>
</body></html>
JSF konwertery i walidatory
Walidator
<p>Podaj ilość osób na utrzymaniu (od 1 do 20):
<h:inputText value'#{userBean.iloscOsobnaUtrzymaniu}” id=”ionu”
required=”true”>
<f:validateLongRange minimum=”1” maximum=”20” />
</h:inputText>
</p>
<h:messages for=”ionu” />
<h:commandButton value=”Ok” />
JSF konwertery i walidatory
Konwerter
<p>Stopa zwrotu:
<h:outputText value=”#{bean.stopaZwrotu}”>
<f:convertNumber type=”percentage” />
</h:outputText>
</p>
JSF konwertery i walidatory
Konwerter i walidator
<p>
<h:inputText value=”#{adresBean.kodPocztowy}” required=”true” id=”kodp”
size=”6”>
<f:validator validatorId=”kodpWalidator” />
<f:converter converterId=”kodpKonwerter” />
</h:inputText>
</p>
<h:message styleClass=”errorMsg” for=”kodp” />
JSF konwertery i walidatory
• Konwertery mogą być powiązane z
komponentami wejściowymi i
wyjściowymi
• Walidatory mogą być tylko powiązane z
komponentami wejściowymi
Konwertery JSF
• Interfejs javax.faces.converter.Converter
zobacz :
http://java.sun.com/javaee/javaserverfaces/1.2/docs/api/
• java.lang.Object getAsObject(FacesContext context, UIComponent
component, java.lang.String value)
• java.lang.String getAsString(FacesContext context, UIComponent
component, java.lang.Object value)
Walidacja i konwersja
Faces
Request
Faces
Response
Restore
View
Apply
Request Values
Process
Validations
Render
Response
Invoke
Application
Update Model
Values
Standardowe konwertery
Converter ID
javax.faces.BigDecimal
javax.faces.BigInteger
javax.faces.Boolean
javax.faces.Byte
javax.faces.Character
javax.faces.DateTime
javax.faces.Double
javax.faces.Float
javax.faces.Integer
javax.faces.Long
javax.faces.Number
javax.faces.Short
Converter class
javax.faces.convert.BigDecimalConverter
javax.faces.convert.BigIntegerConverter
javax.faces.convert.BooleanConverter
javax.faces.convert.ByteConverter
javax.faces.convert.CharacterConverter
javax.faces.convert.DateTimeConverter
javax.faces.convert.DoubleConverter
javax.faces.convert.FloatConverter
javax.faces.convert.IntegerConverter
javax.faces.convert.LongConverter
javax.faces.convert.NumberConverter
javax.faces.convert.ShortConverter
Konwerter DataTime
Postać ogólna:
<f:converterDateTime dateStyle=”dateStyle” locale=”locale”
pattern=”formatPattern” timeZone=”timeZone”
type=”type” binding=”valueExp” />
Przykład użycia:
<h:inputText value=”#{userBean.dataUr}” id=”du” required=”true” >
<f:convertDateTime pattern=”MM-dd-yy” />
</h:inputText> (mm-dd-rr)
<h:message for=”du” />
Java Persistence API
• Część standardu EJB 3.0
• ORM
• Zbudowane na bazie Hibernate i TopLink
Encje
• Encje są zwykłymi obiektami Javy (POJO)
import javax.persistence.*
@Entity
public class Customer {
private int id;
private String name;
@Id @GeneratedValue
public int getId() {
return id; }
public void setId(int id) {
this.id = id; }
}
public String getName() {
return name; }
public void setName(String name) {
this.name = name; }
Encje zarządzanie i niezarządzane
• EntityManager
– centralny dostawca usług związanych z
utrwalaniem danych
– odpowiada za zarządzanie odwzorowaniem
obiektowo-relacyjnym
• Encje zarządzane – połączone z EntityManager,
zmiany w nich są śledzone i synchronizowane z
bazą danych
• Encje niezarządzane – odłączone od
EntityManager, zmiany w niech nie są śledzone
Uzyskiwanie dostępu do EntityManager
• J2EE - metoda 'wstrzykiwania'
import javax.persistence.*;
import javax.ejb.*;
@Stateless
public class FooBean implements FooRemote
{
@PersistenceContext(unitName=”up”)
private EntityManager entityManager;
}
Utrwalanie encji
Customer cust = new Customer();
cust.setName(„Jan Kowalski”);
entityManager.persist(cust);
Wyszukiwanie encji
• Metoda find()
Customer cust =
entityManager.find(Customer.class,
5);
• Metoda getReference()
Customer cust = null;
try {
cust=entityManager.getReference(
Customer.class,5);
} catch(EntityNotFoundException) {
//
}
Aktualizacja encji
@PersistenceContext
EntityManager entityManager;
@TransactionAttribute(REQUIRED)
public void updateCustomerName(int id,
String n) {
Customer cust =
entityManager.find(Customer.class,
id);
cust.setName(n);
}
Scalanie encji
@TransactionAttribute(REQUIRED)
public void mergeCustomer(Customer cust) {
Customer c = entityManager.merge(cust);
}
Usuwanie encji
@TransactionAttribute(REQUIRED)
public void removeCustomer(int id) {
Customer c =
entityManager.find(Customer.class,
id);
entityManager.remove(c);
}
Zapytania
Query q =
entityManager.createQuery(„from Customer
c where id=5”);
Customer cust =
(Customer)q.getSingleResult();
Więcej informacji
• Bill Burke, Richard Monson-Haefel
„Enterprise JavaBeans 3.0”
• http://java.sun.com/javaee/technologies/per
sistence.jsp
Komponenty sesyjne
Komponenty sesyjne (session beans)
• Bezstanowe (stateless) – kolekcja
wzajemnie powiązanych usług
reprezentowanych przez metody
• Stanowe (stateful) – wykonują zadania w
imieniu klienta i utrzymują stan
(konwersacji- conversational state)
właściwy dla danego klienta.
Bezstanowe komponenty sesyjne
• Po zakończeniu obsługi żądania jednego
klienta mogą przystąpić do obsługi żądania
innego klienta
• Nie utrzymują stanu konwersacji – nie
podlegają procesom aktywacji i pasywacji
• Wszystkie dane potrzebne do obsługi
żądania są przekazywane jako parametry*
• Są lekkie i szybkie
Interfejs biznesowy
• Komponent sesyjny może udostępniać
jeden lub wiele interfejsów biznesowych.
• Interfejs biznesowy może być interfejsem
zdalnym lub lokalnym (ale nie może pełnić
obu funkcji jednocześnie)
Rodzaje klientów
• Zdalny klient (dostęp przez zdalny interfejs
biznesowy)
– Może być uruchomiony na innym komputerze
(w innej JVM) niż EJB
– Może być komponentem webowym, aplikacją
kliencką lub innym EJB
– Nie ma dla niego znaczenia lokalizacja
(umiejscowienie) EJB
Rodzaje klientów
• Lokalny klient (dostęp
interfejs biznesowy)
przez
lokalny
– Musi być uruchomiony na tej samej JVM co
EJB
– Może być komponentem webowym lub innym
EJB
– Lokalizacja EJB jest dla niego istotna
Przykład
public interface CommunicationManager {
public boolean sendByEmail(Customer c,
String message) throws CommunicationException;
public boolean sendBySMS(Customer c, String
message) throws CommunicationException;
}
---------------------------------------------import javax.ejb.Remote;
@Remote
public interface CommunicationManager { ... }
---------------------------------------------import javax.ejb.Local;
@Local
public interface CommunicationManager { ... }
Przykład
@Stateless
public class CommunicationManagerBean
implements CommunicationManager {
public boolean sendByEmail(Customer c,
String message) throws CommunicationException
{
// implementacja
}
public boolean sendBySMS(Customer c, String
message) throws CommunicationException {
// implementacja
}
}
Interfejs SessionContext
• Daje dostęp do środowiska kontenera
EJB
• Może być używany do uzyskiwania
informacji o kontekście wywołania metod
Interfejs SessionContext
@Stateless
public class CommunicationManagerBean
implements CommunicationManager {
@Resource SessionContext ctx;
}
Uzyskanie referencji do samego siebie
@Stateless
public class ABean implements ARemote {
@Resource SessionContext ctx;
public void foo() {
ARemote mySelf =
ctx.getBussinessObject(ARemote.class);
}
}
Interfejs EJBContext
• Interfejs bazowy dla SessionContext
http://java.sun.com/javaee/5/docs/api/jav
ax/ejb/EJBContext.html
Cykl życia bezstanowego komponentu
sesyjnego
Stanowe komponenty sesyjne
• Utrzymują stan konwersacji
• Mogą przechowywać dane dla klienta
między poszczególnymi wywołaniami
metod
• Żądanie od jednego klienta muszą być
obsługiwane przez ten sam egzemplarz
• Komponenty nie mają charakteru trwałego
• Pozwalają przenieść logikę biznesową z
aplikacji na serwer
Przykład
@Remote
public interface ShoppingCenterRemote {
public Customer findOrCreateCustomer(String
name);
public boolean addItemToShoppingCart(Item i);
Public void removeItemFromShoppingCart(Item i);
public boolean makeOrder();
}
Przykład
@Stateful
public interface ShoppingCenterBean implements
ShoppingCenterRemote{
// implementacja
}
Użycie z perspektywy klienta
Context jndi = getInitialContext();
Object ref =
jndi.lookup(„ShoppingCenterBean/remote”);
ShoppingCenterRemote b = (ShoppingCenterRemote)
Portable.RemoteObject.narrow(ref,
ShoppingCenterRemote.class)
Cykl życia stanowego komponentu
sesyjnego
When to Use Session Beans
• In general, you should use a session
bean if the following circumstances hold:
– At any given time, only one client has
access to the bean instance.
– The state of the bean is not persistent,
existing only for a short period (perhaps a
few hours).
– The bean implements a web service.
When to Use Session Beans
• Stateful session beans are appropriate if
any of the following conditions are true:
– The bean’s state represents the interaction
between the bean and a specific client.
– The bean needs to hold information about
the client across method invocations.
– The bean mediates between the client and
the other components of the application,
presenting a simplified view to the client.
When to Use Session Beans
• To improve performance, you might choose a
stateless session bean if it has any of these traits:
– The bean’s state has no data for a specific
client.
– In a single method invocation, the bean
performs a generic task for all clients. For
example, you might use a stateless session
bean to send an email that confirms an online
order.
http://java.sun.com/javaee/5/docs/tutorial/doc/
bnbly.html