Diplomova prace - IS MUNI

bandrestInternet και Εφαρμογές Web

15 Αυγ 2012 (πριν από 5 χρόνια και 4 μέρες)

644 εμφανίσεις

Masarykova univerzita

Fakulta informatiky



NetBeans Platform jako EJB klient



diplomová

prác
e

František Holas









Brno, jaro 2009
i


Prohlášení


Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval
samostatně. Všechny zdroje, které jsem při vypracování používal, nebo z nich čerpal, v

práci
řádně cituji
s

uvedením úplného odkazu na příslušný zdroj
.


















Vedou
cí práce: Ing. Petr Adámek

ii


Poděkování


Rád bych poděkoval
Ing.

Petrovi Adámkovi za jeho vstřícný přístup, cenné rady a připomínky.
Dále
všem dotyčným zaměstnancům firmy OXO, kteří mi svými

radami a připomínkami
pomáhali specifikovat a optimalizovat požadavky

na ukázkovou aplikaci a její

rozšíření. Také

bych chtěl poděkovat
svojí rodině

a
především partnerce
, která mi byla
velikou
oporou a
inspirací v

době tvorby této práce.


















iii


Shrnutí


Tato diplomová práce se zabývá

studiem

tvorby vícevrstvých aplikací postavených na
architektuře Jav
a E
nterprise Edition
.

Seznámil
i

js
me

se s

aplikační vrstvou implementovanou
pomocí Enterprise JavaBeans 3.0 a RCP (Rich Client Platform) NetBeans Platform jako
klientskou vrstvu. Pro komunikaci mezi aplikační a klientskou
vrstvou aplikace je použit
rámec pro tvorbu propojení aplikační a klie
ntské vrstvy

pana Lukáše Krejčího v

rámci jeho
bakalářské práce, rovněž z

ob
do
bí jaro 2009. Tyto poznatky byly

využi
ty

při tvorbě ukázkové
aplikace a
ve spolupráci s

firmou OXO js
me

vytvořil
i

aplikaci pro tvorbu zakázek nazvanou
Contractz Platform 2009, kt
erá je postavena na těchto principe
ch a technologiích. Koncept
této diplomové práce js
em

se snažil zvolit tak, aby každý čtenář neznalý těchto princ
ipů a
technologií nabyl postupných


domostí a zkušeností, které js
em
při psaní
této
diplomové
práce získal.

Práce
je
psána s

praktickými ukázkami a postupy, což je velmi užitečné v

době,
kdy ještě není k

dispozici dostatek dokumentace a publikovaných praktických zkušeností.

Čtenář se tak v

závěru práce může rozhodnout, zda jsou popisované postupy a technologie
vhodné pro jeho aplikaci a jak je použít.













iv


Klíčová slova

Rich Client Platform
, NetBeans IDE, NetBeans Platfor
m, Enterprise JavaBeans, Java Enterprise
Edition
, JasperReports, SwingX
, GlassFish V2, API



















1


Obsah


Kapitola 1
: Úvod

................................
................................
................................
................................
..

4

Kapitola 2
:
Architektura Java EE

................................
................................
................................
..........

5

2.1 Java EE platforma

................................
................................
................................
.......................

5

2.2 Java EE aplikační servery

................................
................................
................................
............

9

Kapitola 3
: Enterprise JavaBeans 3.0

................................
................................
................................
10

3.1 Entita

................................
................................
................................
................................
........
11

3.2 Session Bean

................................
................................
................................
............................
13

3.3 Message

Driven Bean

................................
................................
................................
..............
15

3.4 Volání EJB komponent

................................
................................
................................
.............
16

Kapitola 4
: NetBeans Platform

................................
................................
................................
...........
18

4.1 Modulární architektura

................................
................................
................................
............
18

4.
2 Runtime container

................................
................................
................................
...................
21

4.3 Další významná API

................................
................................
................................
..................
22

4.4 Výhody NetBeans Platform

................................
................................
................................
......
23

4.5 První kroky s

NetBeans Platform

................................
................................
.............................
23

Kapitola 5
:
Tisk v

Javě

................................
................................
................................
........................
24

5.1 K

čemu je to dobré

................................
................................
................................
...................
24

5.2 Tvorba výstupu

................................
................................
................................
.........................
25

5.3 Knihovny

................................
................................
................................
................................
...
25

5.4 iReport

................................
................................
................................
................................
......
26

5.5 Práce s

Jasp
erReports API

................................
................................
................................
........
28

5.5.1 Kompilace a naplnění

................................
................................
................................
........
28

5.5.2 Výstup na tiskárnu
................................
................................
................................
.............
29

5.5.3 Výstup do souboru

................................
................................
................................
............
29

5.5.
4 Praktická ukázka

................................
................................
................................
................
30

5.6 Závěrem

................................
................................
................................
................................
...
31

Kapitola 6
: NetBeans Platform jako EJB klient

................................
................................
..................
32

6.1 Úvodní verze

................................
................................
................................
............................
32

2


6.2 Vývojová verze

................................
................................
................................
.........................
34

6.3 Kone
čná verze

................................
................................
................................
..........................
35

6.3.1 Ukázka souboru layer.xml

................................
................................
................................
.
37

6.3.2 Ukázka připojení ke kontextu
................................
................................
............................
37

6.4 Závěrem

................................
................................
................................
................................
...
38

Kapitola 7
: Ukáz
ková aplikace

................................
................................
................................
...........
39

7.1 Současný stav

................................
................................
................................
...........................
39

7.2 Navrhované řešení

................................
................................
................................
...................
40

7.3 Contractz Platform 2009

................................
................................
................................
..........
40

Kapitola 8
: Aplikační vrstva

................................
................................
................................
...............
42

8.1 Cenová nabídka (Bid)

................................
................................
................................
...............
44

8.2 Dodací List (
DeliveryNote
)

................................
................................
................................
........
45

8.3 Faktura
(Bill)

................................
................................
................................
.............................
45

8.4 Příjmový pokladní doklad (
Receipt
)

................................
................................
.........................
45

8.5 Výdajový pokladní doklad (
Disbursement
)

................................
................................
...............
45

8.6 Reklamace (
Reclamation
)

................................
................................
................................
........
46

8.7 Skladová karta (
DefinedItem
)

................................
................................
................................
...
46

8.8 Klient (
Client
)

................................
................................
................................
............................
4
6

8.9 Proj
ekt (
Project
)

................................
................................
................................
.......................
46

8.10 Další vlastnosti aplikační vrstvy

................................
................................
..............................
47

8.10 .1 Generování ID entitních tříd
................................
................................
...........................
47

8.10.2 Výčtové typy

................................
................................
................................
....................
47

8.10.3 P
refix dokumentů

................................
................................
................................
............
48

Kapitola 9
: Klienstká vrstva

................................
................................
................................
...............
49

9.1 Modul
Core

................................
................................
................................
...............................
50

9.2 Modul
DataOutput

................................
................................
................................
...................
51

9.3 Modu
l
Nodes

................................
................................
................................
............................
53

9.4 Modul TopComponents

................................
................................
................................
...........
55

9.4.1 Cenová nabídka (
BidTopComponent
)

................................
................................
................
56

9.4.2 Dodací list (
DeliveryNoteTopComponent
)

................................
................................
.........
57

9.4.3 Faktura (
BillTopComponent
)

................................
................................
.............................
58

3


9.4.4 Příjmový pokladní doklad (
ReceiptTopComponent
)

................................
..........................
60

9.4.5 Výdajový pokladní doklad (
DisbursementTopComponent
)

................................
...............
61

9.4.6 Reklamace (
ReclamationTopComponent
)

................................
................................
.........
62

9.4.7 Skladová karta (
ItemTopComponent
)
................................
................................
................
63

9.4.8 Klient (
ClientTopComponent
)

................................
................................
............................
64

9.4.9 Projekt (
ProjectTopComponent
)

................................
................................
........................
65

9.4.10 Procházení vizuálních dat (
ExplorerTopComponent, BrowserTopComponent
)

..............
66

Kapitola 10
: Závěr
................................
................................
................................
..............................
68

Literatura

................................
................................
................................
................................
............
69

Dodatek A

................................
................................
................................
................................
...........
71


















4


Kapitola 1

Úvod


Obecně lze říct, že neznalost vhodných technologií brání programátorům psát snadno
rozšiřitelné a dobře ud
ržovatelné aplikace. Č
asto
se
setkávám
e

s

lidmi,

kteří pracují ve
firmách, kde

nepracují s

dost pokročilými technologiemi
,

nebo neprosazují kulturu
pravidelného a systematického vzdělávání svých zaměstnanců. Používají tedy základní
technologie a podle toho ta
ké vypadá jejich zdrojový
kód a efek
tivita

práce s

ním
.

S

programovacím jazykem Java jsem se seznámil až v

době magisterského studia na
Masarykově Univerzitě v

Brně,

ale okamžitě jsem jej začal preferovat
, protože velmi
jednoduchým, přehledným

a promyšleným způsobem přináší

to, o čem jsem si mohl nechat
u
jiných programovacích jazyků, jako například rodina C/C++,

jen zdát.
Studium v

navazujících
předmětech

mi ukázal
o další promyšlená

API
1

a já jsem tím pochopil, že jejich vhodnou
kombinací lze ušetřit mnoho času a finančních

prostředků. Studium dalších technologií
v

rámci této diplomové práce jsem uvítal, protože tyto technologie se mi jeví jako velmi
perspektivní a jejich kombinace je dle mého názoru přínosná.

Pochopil jse
m výhody pokročilých řešení, ve kterých

je aplikace vhodným způsobem
rozdělena do několika částí, kdy program již nepředstavuje jen
tzv.
špagetový kód
. Ten

se
špatně udržuje a ještě pracněji rozšiřuje.

Ukazuje to nutnost místo aplikace, která v

jednom
kódu spravu
je celý cyklus programu a správu

všech technologií,
programovat aplikace, kde
logiku

jednotlivých technologií rozdělíme do vrstev.

Není s

podivem, že řešením může být Java EE
2

architektura, která je určena pro
rozsáhlé podnikové aplikace, u nichž je vývoj rozdělitelný do vrstev naprosto
zásadní.
Podrobnějším studiem Java EE architektury a implementací jednotlivým vrstev se zabývají
následující kapitoly.

Tuto myšlenku ještě více rozvin
eme
, protože potřebuj
eme

do vícevrstvé
aplikace zakomponovat jako klientskou vrstvu NetBeans Platform, RCP
3

vyvinuté pro
jednovrstvé aplikace. Propojení NetBeans Platform se zbytkem architektury ukázkové
aplikace bude využívat aplikační rámec pana Lukáše Krejčího, který se
touto problematikou
zabývá.

Dále předvedeme

šikovná

API pro tisk sestav a export

do známých typů souborů v

Javě
a popsa
né technologie si
vyzkouším
e

na

ukázkové aplikaci. Ta nám mimo jiné prokáže
vhodnost resp. nevhodnost koncepce bakalářské práce pana Lukáše Krejčího

a především
vhodnost vícevrstvých aplikací jako takových
.




1

API = Application Programming Interface, což znamená
rozhraní pro programování aplikací.

2

Java EE = Java Enterprise Edition

3

RCP = Rich Client Platform

5


Kapitola 2

A
rchitektura

Java EE


Java Enterprise Edition

architektura používá vícevrstvý
distribuovaný
aplikační
model, což
přináší rozdělení systému do několika vrstev nezávislých na sobě.



Obrázek
1
: Aplikace rozdělená do vrstev


Tyto

vrstvy spolu komunikují přes Java
EE API, které definuje rozhraní mezi vrstvami
a komunikaci mezi nimi. Tyto rozhraní jsou standardizované
, což přináší řadu výhod.
Umožňuje nám to vyměnit implementaci konkrétní použité technologie, aniž bychom museli
měni
t kód v

našem programu.

Výhodou pro programátora je snazší programování aplikace, kdy se stará jen o
konkrétní problém ve své aplika
ci, za
tímco volba konkrétní
technologie

na libovolné vrstvě je
ošetřena jinde.
Je tedy kladen důraz na rozšiřitelnost a udrž
ovatelnost aplikace za
jednoduchých principů programování.


2.1
Java
EE platforma


Platforma Java EE byla vytvořena s

cíle
m poskytnout jednoduchý standard

při vytváření
rozsáhlých aplikací a podpořit rozsáhlou škálu požadavků při jejich vytváření v

souladu s

Java
EE architekturou.
Je přitom založena na vícevrstvém distribuovaném aplikačním modelu.
Obrovskou výhodou vícevrstvého modelu je možnost využívat ne
závislých serverů při
6


poskytování služeb jednotlivých vrstev, ale
tyto služby
mohou také běžet všechny na jednom
serveru.



Java
EE architektura definuje tyto vrstvy:



Klientská vrstva

(
front
-
end tier
)


podporuje
mnoho různých typů klientských aplikací
.



Střední vrstva

(middle tier)


p
oskytuje podporu
klientské vrstvě prostřednictvím Web
kontejnerů nebo např. aplikační logiku pomocí
EJB (Enterprise Java Beans)
.



Back
-
end vrstva
(back
-
end tier)


umožňuje
přístup k

existujícím informačním systémům a
zdrojům

dat (databáze, ERP, …)
.



Obrázek
2
: Interakce vrstev


Java
EE aplikace může být složena z

různých
komponent

zajišťující
ch

různou
roli:



Klientské komponenty



zpravidla se jedná o
programy programované v

jazyce Java, běžící na
klientském počítači uživatele (GUI). Navenek
mají stejnou funkcionalitu jako jiné aplikace,
ovšem umožňují přístup ke střední vrstvě
Java
EE aplikace.

7




Webové komponenty



běží na straně

serveru a
generují výstup dle požadavků klienta. Jedná se
např. o servlety a JSP stránky.



Business komponenty



zajišťují business logiku
aplikace a práci s

daty.


Základní aplikační
komponenty:



Servlety



objekt generující HTTP
4

odpovědi na
základě HTTP požadavků.



JSP

(Java Server Pages)
-

generování
dynamických dokumentů pro webový prohlížeč.
Do HTML jsou vkládány prvky kódu servetů (JSP
elementy).



JSF

(Java Server Faces)


rámec pro
implementaci uživatelského webového rozhraní
.



EJB

(Ent
erprise Java Beans)


viz kapitola 3.



JDBC

(Java Database Connectivity API)


aplikační API pro provádění SQL dotazů a
příkazů.



JAX
-
WS

(Java API for XML Web Services)


podpora webových služeb pomocí JAXB API
mapující XML data na Java objekty
.



JPA

(Java Persistence API)


provádí ORM
mapování Java objektů. Poskytuje API pro
perzistenci objektů, dotazovací jazyk a potřebná
metadata
.



D
alší (Java Transaction API, Java Message
Service API, JavaMail API, Java Naming and
Directory Interface, Java Auth
entication and
Authorization Service, …)
.


K
omponent
ě

přitom zajišťují
běhovou podporu
kontejnery
.
Kontejner

zajišťuje

úplné
aplikační prostředí po c
elý životní cyklus
komponent
y

a poskytuje
jí různé služby
:



Rozhra
ní mezi komponentou a platformově

závislým

prostředím
.



Komponent
a je

nasazen
a

v

kontejneru
.



Kontejnery zajišťují komponentám různé služby
.




4

HTTP


HyperText Transfer Protocol je internetový protokol pro přenos informací.

8



Typy kontejnerů:



k
ontejner klientské aplikace
;



w
ebový kontejner
;



EJB kontejner
.


Kontejnery zajišťují:



b
ezpečnost
;



d
ostupnost
;



p
erzistenci
;



r
ozšiřitelnost
;



ř
ízení životního cyklu
;



s
ynchronizace
;



t
ransakce
.



Obrázek
3
:

Komponenty v kontejneru


Základem Java EE je Java SE (Java Platform,
Standard
Edition), která poskytuje
komponentám a kontejnerům základní funkční API.



9


2.2
Java
EE
ap
likační servery


Běhovým prostředím pro každou Java
EE aplikaci jsou tzv.
aplikační servery
. Naše

aplikace by
měla být teoreticky

schopna běžet pod jakýmkoliv aplikačním serverem, který implementuje
přísluš
nou verzi specifikace. Prakticky

každý aplikační server však poskytuje také služby nad
rámec specifikace a aplikace využívající těchto služeb nejsou dále přenositelné.

Aby
aplikace mohla být prohlášena
za
Java
EE kompatibilní, je

nutno provést
certifikaci

u
Sun

Microsystems

Inc
. Protože
jsou zde i různé politické tlaky, vyskytují se i
servery bez označení kompatibility, které ovšem danou specifikaci splňují.

Open Source Java EE aplikační
servery:



Apache Tomcat

(částečná implementace)
;



GlassFish
;



JBoss
.


Komerční Java EE aplikační
servery:



IBM WebSphere
;



BEA WebLogic
;



Sun Java Systém Application Server
;



Oracle AS
.












10


Kapitola 3

Enterprise Java Beans

3.0


Enterprise JavaBeans

(EJB)
je komponentová architektura,
slouží


jako aplikační vrstva Java
EE aplikace.

EJB komponenty, tvořící vlastní aplikační logiku, implementuje vývojář.

Aplikace
napsané pomocí EJB jsou škálovatelné, umožňují transakce a jsou zabezpečeny ve
víceuživatelském prostředí.
Většina služeb je řízena kontejnerem a jejich nastavení probíhá
de
klarativní
m

způsobem. Mezi nej
důležitější vlastnosti EJB patří

interoperabil
ita
nejen mezi
jednotlivými kontejnery a aplikačními servery, ale i s

jinými aplikacemi prostřednictvím
protokolu
RMI
-
IIOP
.



Obrázek
4
: Interakce EJB s
okolím


EJB komponenty ke své činnosti vyžadují kontejner, který:



Ř
ídí její životní cyklus
.



Z
ajišťuje autentizaci a autorizaci (JAAS)
.



U
možňuje distribuci komponent (RMI
-
IIOP)
.



Ř
ídí transakce (JTA)
.



M
ůže zajišťovat perzistenci (JPA)
.



P
oskytuje přístup ke
zdrojům a dalším službám
.


Nastavení atributů používaných služeb je odděleno od vlastního kódu a řeší se
deklarativním způsobem, v

EJB 3.0 nasazením tzv.
anotací
.

11


Aplikace připravené k

používání jsou zabaleny do
JAR

archivu a nasazeny

do
kontejneru aplikačního serveru.
Stejná aplikační logika tedy může běžet na více různých
aplikačních serverech. Tyto aplikační servery musí rovněž vyhovovat specifikačním
standardům

EJB.
Standardizace

v

této oblasti nám přináší řadu dalších výhod:



D
istr
ibuce a vypuštění aplikace jsou
zjednodušeny
.



K
líčové vlastnosti mohou být poskytovány
přímo aplikačním serverem
.



I
nteroperabilita
,

jak mezi komponentami a
aplikačními servery, tak mezi cizorodými
systémy
,

prostřednictvím RMI
-
IIOP nebo JMS
.


V

našem případ
ě využíváme verzi
3.0
, která oproti předchozí verzi
2.1

přináší mnohá
zjednodušení, vylepšení a tím i pohodlnější práci.

Jedná se zejména o nahrazení entit
Entity
EJB

ke klasickým POJO entitám a nahrazením
depende
n
cy injection

tzv.
anotacemi
.

EJB komponenty můžeme vzhledem k

jejich variabilitě rozdělit do několika
skupin:



entity
;



session bean
;



message

driven


bean
.


Cílem použití EJB je přenechat veškerou aplikační logiku na EJB, zatímco klientská
vrstva, která aplikační logiku využívá, se bude starat například o GUI vzhledem ke koncovému
uživateli a s

EJB komunikovat přes
komponenty typu session bean a message

driven

bean
.


3.1
Entit
a


Entity představují objekty, instance příslušných tříd, které jsou pomocí ORM
5

mapovány
do
úložiště

dat, typicky databáze.
Entity lze považovat za základ celé aplikační logiky.

Například
objekty
Lednice

a
Mikrovlnka

jsou instancemi, entitami, entitní třídy

Product
. Pokud bychom
se podívali do databáz
e, hledali bychom tabulku
Product

(není
-
li pomocí anotací
tabulka
explicitně pojmenována

jinak) a v

ní dva řádky představující jednotlivé instance.
Tyto instance
jsou v

p
odstatě serializovány
6

místo na disk do databáze.
V

případě EJB 3.0, které je zároveň



5

ORM = Object Relational Mapping = mapování objektů na položky relační databáze.

6

Serializace = Speciální

druh anotace, která říká, že objekt může být transformován na proud symbolů, které
reprezentují vnitřní strukturu nějakých informací tak, aby přečtením proudu bylo možno vnitřní strukturu
zpětně zrekonstruovat.

12


implementací JPA (Java
Persistence

API), s

entitami pracujeme jako s

POJO
7

objekty
. Pomocí
anotací píšeme do entit speciální metadata, která jsou dostupná pro
programátora i pro EJB
kontejner za běhu aplikace.

Každá třída musí splňovat
následující:



Být serializovatelná, tedy implementovat
přísl
ušné rozhraní, typicky
je to
java.io.s
erializable
.



Mít bezparametrický konstruktor
.



Atributy
mít
přístupné pomocí get a
set metod
.



Přístup ke sdíleným souborům musí podporovat
souběžnost
.


Nastavení atributů používaných služeb je odděleno od vlastního kódu a řeší se
deklarativním způsobem, v

EJB 3.0 nasazením tzv.
anotací
.


Příklad:

@Entity

p
ublic class Product

implements Serializable
{



@Id


private Long rc;


pri
vate String name
;


public Product
() {


rc = (int) System.nanoTime();


surname = “Lednice”;


}

… get a set metody pro proměnné

}


Jak vidíme, i tato velmi jednoduchá ukázka třídy

Product

obsahuje dvě anotace.
První anotace

@Entity

označuje
, že se jedná o entitní třídu, druhá s

označení
m

@Id

zase



7

POJO = Plain Old Java Object. Objekt, jeho
ž třída musí obsahovat bezparametrický konstruktor a pro každý
atribut musí obsahovat get/set metody, které vrací/vkládají údaje z/do atributů.

13


říká, že proměnná pod touto anot
ací bude brána jako jedinečný identifikátor

v

databázové
tabulce. Anotací je samozřejmě mnohem
více, pro
podrobnosti doporučujeme

prostudovat
dokumentaci EJB.

Kromě primitivních

datových
typů může e
ntita obsahovat i uživatels
ky definované
typy objektů, jejich

kolekce apod. Tyto typy mohou být doprovázeny dalšími anotacemi, které
říkají EJB, jak mají s

danou e
ntitou zacházet,
například při tvorbě tabulky
relační databáze.

V
ýhoda
entit spočívá

p
ředevším

v

tom, že s

nimi můžem
e manipulovat přímo jako
s

objekty,
aniž bychom

museli
dat
a manuálně posí
lat a vyhledávat v

databázi
. Pro ty, kdo ví,
jak pracné je starat
se o tuto činnost manuálně, to jistě představuje výrazné usnadnění.


3.2
Session Bean


Session B
ean představuje

aplikační logiku. P
rávě zde jsou implementovány algoritmy p
ro
práci s

entitami, například zpracovávají objednávky, nebo

počítají platby. Slouží
pro
zpracování požadavků, které na ně klient vznese.
Na rozdíl od jiných komponent, session
b
eany

mají poměrně krátký životní cyklus.
Ten začíná, jakmile si

na něj klient vy
tvoří
referenci a končí, když

tato reference

pozbude platnosti. Není zde žádná gara
nce, že příště
dostan
e
me

k

dispozici stejnou instanci session b
ean.
Ta

může trvat, dokud budem
e mít ve
webovém prohlížeči ote
vřené příslušné okno, než zavřem
e okno v

klientské aplikaci, nebo ne
ž
bude jiný bean používat n
áš b
ean.

To představuje rozdíl
vzhledem k

entitám, které jso
u trvale uloženy v

databázi. U
komponent typu
session b
ean

se tohle neděje. Není třeba mít je ně
kde trvale uloženy. Přesto
ale session b
eany dělíme na ty
to
kategorie:



@
Stateful



udržuje stavové informace své
instance napříč je
dnotlivými voláními. Například
vnitřní proměnná má hodnotu, která je
uchována při každé manipulaci s

ní. V

dané
chvíli s

ní nemůže pracovat nikdo jiný. Zabírají
v

paměti určité místo, je jich k

dispozici
méně,
nejsou tedy vhodné pro velké zátěže.

Nelze je
použít například ve webových prohlížečích.



@
Stateless



naopak neudržuje stavové
informace napříč jednotlivými voláními.
Může je
tedy volat více různých
tazatelů, a protože

jsou
méně náročné na paměť, může jich být více.


14


Session beany

představují synchronní varian
tu komunikace. Na dotaz dostanem
e
odpověď.

N
evoláme

je však

přímo, nýbrž pomocí vyb
raných rozhraní. Tyto rozhraní dělíme do
dvou druhů:



@
Local



tuto anotaci použijeme, pokud víme, že
klient bude pracovat ve stejné JVM
8
, jako naše
EJB. Je to ovšem
rychlejší

varianta, protože dané
vrstvy spolu komunikují přímo v

rámci jedné
JVM.



@Remote



tuto anotaci naopak použijeme
v

situaci, kdy víme, že budeme pracovat
v

distribuovaném prostředí, tedy že klient bude
pracovat pod jino
u JVM, než EJB.

Je to ovšem
pomalejší varianta

daná tím, že tyto JVM jsou
různé a je zde potřeba

komunikace. Této
varianty můžem
e využít
,

i pokud bude klient
nasazen ve stejné JVM jako EJB, ovšem za cenu
menší rychlosti.


Příklad:


@Stateless

public class
ProductBean implements ProductRemote {



@PersistenceContext


private EntityManager em;



public void addProduct(Product product) {


em.persist(product);


}

}


@Remote

public interface ProductRemote {



public void addProduct(Product product
);

}





8

Java Virtual Machine. Virtuální stroj, pod kterým běží aplikační server.

15


3.3
Message

Driven Bean


Tato komp
onenta používá asynchronní formu

komunikace. My jí posíláme data do fronty, a
jakmile přijd
ou data na řadu, jsou zpracována
. Je to vhodné například pro systémy, kde je
očekávána velká zátěž a jen za té podmínky, kdy
nepotřebujeme nějakou odpověď

od serveru
.
Používáme ji

například při zasílání nových dat do databáze.

Je při tom využívána technolo
gie
JMS
9
, kdy jsou data posílána ve formě zprávy.

Vytvoříme tedy příslušnou zprávu, odešleme jí
serveru a ten ji zařadí do fr
onty. Jakmile přijde na řadu dotyčný záznam

fronty
,
předá

ji

komponentě typu Message

Driven Bea
n

a ten ji zpracuje.


Příklad:

@MessageDriven(mappedName="jms/Queue")

public class SimpleMessageBean implements MessageListener {



@Resource


private Messa
geDrivenContext mdc;



public void onMessage(Message inMessage) {


TextMessage msg = null;


try {


if (inMessage instanceof TextMessage) {


msg = (TextMessage) inMessage;


logger.info("
MESSAGE BEAN: Message received:
"




+

msg.getText());


} else {


logger.warning("Message wrong type: "



+inMessage.getClass().getName());


}


} c
atch (JMSException e) {


e.printStackTrace();


mdc.setRollbackOnly();




} catch (Throwable te) {




te.printStackTrace();


}


}

}





9

JMS = Java Messaging Service. Služb
a pro posílání zpráv.

16



3.4
Volání EJB komponent


Ukázali jsme si typické, i

když velmi zjednodušené, ukázky
komponent v

rámci EJB

a práci s
nimi
. Nicméně tyto komponenty fungují v

rámci EJB a my s

nimi
musíme

nějakým způsobem
komunikovat

Pokud používáme aplikačního klienta jako sou
část Java EE aplikace, můžeme
příslušnou komponentu typu Session Bean

volat napřík
lad takto:


public class Test
{


@EJB

private static ProductRemote pr;


public void Test() {



Product product = new Product();


pr.addProduct(product);

}




Jestliže máme samostatný EJB modul a samostatného aplikačního klienta, příslušnou
komponentu typu Session Bean voláme například takto:


public class Test
{


private static InitialContext ctx;

private static ProductRemote pr;


public void Test() throws
NamingException {



ctx = new InitialContext();


pr = (ProductRemote) ctx.lookup
(ProductRemote.class.getName());



Product product = new Product();


pr.addProduct(product);

}

17


Protože vytváření instancí rozhraní a vytváření kontextu je časově velmi

náročný
proces, doporučuje se např. vytvořit speciální třídu, která bude tyto instance spravovat.
Třídám, které tyto instance potřebují, budou přes tuto třídu poskytnu
ty. Rovněž se tak
zpřehlední zdrojový

kód

aplikace
.

V

této podkapitole b
yl nastíněn pouz
e

velice jednoduchý názorný příklad, jak s

EJB
pracovat, nicméně pro prozkoumání možností používání všech výhod,

které EJB poskytují,
doporučujeme

prozkoumat dodatečné informace, například
(4)
.

Tato kniha

je

velmi dobře a
snadno uc
hopitelně napsána, takže
je možné rychle si osvojit

potřebné znalosti.
Jsou zde
publikovány základní i pokročilé možnosti např. pro tvorbu inheritance entit, transakční
zpracování, používání webových služeb apod.
K

většině
témat

jsou zde publikovány příklady
zdrojového
kódu.


















18


Kapitola 4

NetBeans Platform


Když se řekne slovní spojení NetBeans Platform, mnozí si jistě řeknou, proč používat další
framework
10
, když už známe například Swing
11

framework
. NetBeans
Platform
nabízí
ne
jen
ucelenou sadu komponent a podpůrných
tříd
, nýbrž
propracovanou

modulární architekturu
s

konkrétními promyšlenými API, které výrazn
ě urychlí vývoj a správu
programů. Křivka
učení není
tak strmá, ale jakmile pochopíme základní souvislosti, dostanem
e do rukou velmi
mocný nástroj. Množství dokume
ntace zatím není tak velké, ale postupně se rozšiřuje,
především dí
ky rozšiřujícím
u

se portfoliu programátorů, kteří s
i výhody tohoto frameworku

uvědomují
. K

dis
pozici jsou například základní

tutoriály

na oficiálních strán
kách NetBeans
Platform. V
ýborná je

také výrobcem doporučená kniha
, viz (5)
.



4.1
Modulární architektura


Jedná se o jeden z

nejdůleži
tějších aspektů programování s

NetBeans Platform. Základní
problém dodnes vyvíjených aplikací je tzv.
špagetový kód
. Toho programátor obvykle dosáhne
postupným rozšiřováním jednoho velkého programu, který se postupným rozšiřováním a
upravováním stává více a více nepřehledným, i

když se snažíme program co nejvíce
organizovat, například tříděním do hierarchie balíků. To
j
e ovšem

ten lepší případ. Horší

si
tuace nastane, pokud dostane program k

přepracování jiný programátor. Ukázkový případ
velkých problémů ale nastane, jakmile je například požadováno část programu vyřešit jiným
způsobem, i

když
třeba
pouze pro tento jeden případ.

Řešením problému může být m
odularizace, tedy rozdělení programu do modulů, které
spolu budou vhodným způsobem propojeny.
Jedná se o velmi důležitou, stěžejní část
pochopení architekt
ury NetBeans Platform, která začátečníkům obvykle chvíli potrvá
.
Z
kušenosti
však
ukazují, že každý
program může být dekomponován do systému modulů.

Výhody

modulárního systému jsou mnohé
:



P
rogram je sestaven

z

nezávislých modulů
.



M
oduly mohou být vyvíjeny nezávislými týmy
po celém světě
.




10

Framework = softwarová architektura, která slouží jako podpora pro programování při vývoji jiných
softwarových projektů.

11

Swing = framework pro zjednodušení tvorby GUI aplikací.

19




P
ro každého zákazníka

lze sestavit program
z

jiných modulů
.



M
odul
může být nahrazen jiným ekvivalentem
.


NetBeans Platform posunuje modulární architekturu

trošku výše. Aktivně se stará o
načítání modulů za běhu programu (pokud jsou takto nastaveny), a vynucuje jejich
deklarovanou minimalistickou verzi.
Moduly spojené do
výsledné aplikace jsou propojeny
vhodným způsobem:



M
odul A závisí na modu
lu B, pokud má modul B
zveřejněné

vybrané
balíky
12
.



M
odul A a modul B mohou být nezávislé. K

tomu,
aby se modul B dozvěděl o tom, že je potřeba
vykonat nějakou činnost
, která probíhá
na
modulu A
, slouží Lookup API
13
.



M
odul A slouží jako jádro aplikace,
na
příklad
s

definovanými rozhraními.
Moduly B, C…

jsou
závislé na modulu A, obsahují implementace
vybraných rozhraní

modulu A
, které jsou
v

modulech B, C …

zaregistrovány.



Ž
ádné dva modul
y nesmí být mezi sebou závislé
.


Vzájemná závislost modulů
je
zakázána, protože se tím především přichází o výhody
používání modularity. Praxe ukazuje, že každá závislo
s
t může být dále dekomponována.

Výsledek dekompozice spočívá v

tom, že modul A je závislý na modulu B, zatímco modul B
volá funkce modulu A přes Lookup API.
Postup může být

například tento
:



Rozhodneme, který modul se na druhý modul
odvolává více. Řekněme, že modul A je více
závislý na mo
dulu B, než modul B na modulu A.



Modul A tedy bude dále závislý na modulu B.



Modul

A, na němž je modul B

méně závislý,
vyextrahuje svoje potřebné rozhraní do nového
modulu

C
, nebo třeba do modulu s

jádrem

C
, jak
jsme uváděli výše
.



Třídy v

modulu

A
,

které i
mplementují

rozhraní
modulu C
,
zaregistrují v

modulu A



12

Balík (angl. package) = logická složka obsahující p
odsložky nebo soubory, například třídy a rozhraní.

13

Lookup API je zodpovědný za komunikaci mezi moduly, které mezi sebou nemají nastavenou přímou
závislost.

20


implementující tří
dy (vytvořením souboru
v

balíku META
-
INF/services)
.




Modul B si nastaví závislost na modulu C
s

rozhraními.



Volání v

modulu B na třídy obsažené původně
v

modulu A, budou nyní přístupn
é přes Lookup
API na
rozhraní

v

modulu C
.



Obrázek
5
: Odstranění křížové závislosti mezi moduly A, B


Podrobná ukázka je k dispozici

na
oficiálních webových stránkách

portálu NetBeans
Platform
, v

sekci tutoriály

(12),

seriál nazvaný
WordApp Example
.

Moduly ovšem představují také knihovny.
Moduly dodané výrobcem představují
knihovny, kterých můžeme využívat

ihned
. Můžeme vytvářet i knihovny vlastní. V
ytvoříme
speciální modul, tzv.
Library wrapper
. Ten potom

obsahuje jed
nu či více knihoven, které
budeme potře
bovat.

Modul s

kódem, který bude knihovny potřebovat, si na ně, podobně jako
na jiné moduly
,

nastaví zá
vislost. J
e

to proto,
aby každý modul používal jen ty knihovny, které
potřebuje a tím byl program méně
rychlý

a kompaktnější.

Cílem této podkapitoly b
ylo ukázat
základní
vlastnosti modulárního systému a fakt, že
každý

program, i ten sebeprovázanější, lze dekomponovat na systém modulů.



21


4.2
Runtime container


NetBeans Runtime Container není nic jiného než název p
ro 5 modulů, které
musí

být u

každé
aplikace, kterou programujeme
:


Obrázek
6
: Základní moduly




Bootstrap



umožňuje kontejneru pochopit co modul
je a jak je
j

načítat a skládat do výsledné aplikace
.



Startup



poskytuje hlavní metody aplikace a kód
potřebný pro
její
start
.



Filesystem API



poskytuje
přístup nejen
k

souborovému systému, ale je také n
ástrojem pro
správu abstraktních souborových systémů
, které je
možno mapovat jako XML soubory. Můžeme také
dekla
rativně měnit viditelné vlastnosti programu,
jako uspořádání položek menu, ukládání vlastností,
apod.



Module S
yste
m API



stará se o životní cyklus
modulů v

aplikaci
.



Utilities API



poskytuje
soubor

pomocných tříd,
například třídu
Lookup

pro komunikaci mezi
moduly
.


22


Tyto moduly představují absolutní minimum, které

je pro chod aplikace potřebný.
Další API z

knihovny

rozšiřují možnosti aplikace, pro
to doporučujeme prozkoumat, jaká

API

platforma obsahuje.


4.3 Další významná

API




Actions API


rozhraní pro přístup k

běžným

akcí
m

používaných v

r
ámci NetBeans Platform. Povoluje
nám

deklarovat kontextově závi
slé akce
a menu. Je
to užitečné tam, kde již

nestačí
standard

Swing
Actions
.



Dialogs API



nadstavba
uživatelského rozhraní
pro
tvorbu dialogů.



Explorer
& Proper
ty Sheet API



Explorer API

slouží
k

vykreslování hierarchie uzlů, resp. některé její
podčásti a zajišťuje zobrazovací akce k

nim
přidružené. Typ zobrazení je závislý na vybrané
komponentě (
BeanTreeView, TableTreeView
,
…).
PropertySheet API

slouží k

zobrazování a editaci
vlastností uzlů.
Obsahuje dva sloupce, v

levém je
název atributu, v

pravém příslušný propertyEditor
pro úpravu toho atributu.



Nodes API



slouží k

zobrazování objektů do
hierarchie uzlů, ke kterým jsou d
ostupné akce a
vlastnosti, je tedy úzce svázána s

Explorer

&

Proper
t
y
Sheet API
.



Settings API



rozhraní pro práci s

nastavením

a
vlastnost
m
i uživatelské aplikace
.



Window Systém API



rozhraní pro zobrazování
vizuálních dat uživateli, nezávislé
na
konkrétním
operačním systému a služby s

nimi spojené, např
.
perzistenci pozice

okna mezi
jednotlivými
sezeními

a manipulace s

nimi.


Platforma obsahuje desítky další
ch zajímavých a praktických modu
lů.

Pro jejich
zobrazení doporučujeme

nahlé
dnout do knihovn
y modulů ve vytvářené

aplikaci.



23


4.4 Výhody NetBeans Platform


Moderní koncept vývoje
programů pod touto platformou přináší i další výhody. Na platformě,
která vznikla především pro vlastní vývojové

prostředí,
exis
tuje spousta vymožeností, které

můžeme ihned začít používat, aniž bychom museli něco podobného vyvíjet sami.

Můžeme využívat výhod pokročilých pro
pracovaných API, používat moduly
, které
napsal někdo jiný jako plugin
y, které

jednoduše přidáme do aplikace. Můžeme používat
možnosti Auto Up
date, kdy mohou být aktualizovány pouze vybrané moduly. Můžeme se tak,
jak je neustále připomínáno, soustředit na
vlastní vývoj
.


4.5
První kroky s

NetBeans Platform


Naučit se programovat pod NetBeans Platform není tak snadné. Sám jsem před psaním této
diplomové práce neměl s

NetBeans Platform
žádné

praktické zkušenosti. Navíc stále není k
dispozici dostatek materiálů pro samostudium.

Pro

začátek doporučujeme

podí
vat
se na tutoriály
na webových stránkách věnovaným

portálu Ne
tBeans Platform

(12)
, zejména

CRUD
14

Application Tutorial

a
Selection Management
Series
.
K

dispozici jsou také videa v

angličtině
TOP 10
NetBeans

API´s
.

Bohužel,
zatím
zřejmě
nejucelenější kniha věn
ující se této problematice
,

Rich Client
Programming: Plugging into
NetBeans

Platform

(5)
, napsána přímo lidmi věnujícími se vývoji
NetBeans Platform a NetBeans IDE samotnému, není
snadno pochopitelná

pro úplné
začátečníky. N
avíc většina kapitol není dost podrobná a užitečná jako
výše
zmíněné tutoriály.

Doporučujeme také navštívit blogy lidí, kteří se věnují vývoji platformy, kde jsou
řešeny mnohé problémy a také užitečné

rad
y

s

praktickými ukázkami.

Za zmínku stojí také tzv. dvoudenní intenzivní školící kurz
NetBeans Platform Certified
Training
, pořádaný

přímo firmou Sun. Aktuální seznam pořádanýc
h kurzů s

daty a místy je k
dispozici

na
webových
stránkách
,
viz
(1).

Každý, kdo úspěšně projde kurzem, ob
drží jeden ze
tří certifikátů dle výkonnosti, kterou během kurzu prokázal.








14

CRUD = Create Read Update Delete.

24


Kapitola 5

Tisk v Javě


Jedním ze

základních problémů, kterým js
m
e

čelil
i

při návrhu
ukázkové aplikace
, byla vhodná
forma výstupu dat. Každý program zabývající
se
tématikou

jako ukázková aplikace,

potřebuje
minimálně tiskový výstup a optimálně také výstup do nějakého vhodného formátu, který by
mohl být případně dále upravován v


jakém externím programu, či
například dále rozesílán
obchodním partnerům
.

Programovací jazyk Jav
a disponuje rozsáhlým spektrem knihoven pro
nejrůznější

oblasti užití. Bohužel, nějakou zásadní
vestavěnou
podporu pro tisk v

Javě bychom hledali
marně. Protože je ale tato oblast pro
mnoho

vyvíjených aplikací naprosto zásadní, byla
vytvořena
ucelená

kniho
vna funkcí s

názvem
JasperReports
.


5.1 K

čemu je to dobré


JasperReports je knihovna funkcí pro podporu tisku v

Javě, která byla vyvinuta na

portálu
JasperForge

(2)
, open
-
source vývojové komunitě

v

rámci
JasperSoft
projektů. Díky velkému
počtu uživatelů i vývojářů postupně vzniká velice robustní nástroj, který se rychle vyvíjí a je
k

dispozici zdarma v

rámci
LGPL
15

licence
.
Tato sada knihoven pracuje s

XML

dokumenty
.
Krom tisku využívá další k
nihovny, díky nimž umožňu
je

uložení výstupu do souboru ve
formátech
PDF
,
ODT
,
RTF
,
XLS single
-
sheet
,
XLS
multi
-
sheet
, CSV
,
HTML

či
XML
.

JasperReports
jako celek
se
skládá z:



Knihovny funkcí
JasperReports
.



Nástroje pro tvorbu šablon
iReport
.



Podpůrných knihoven
.


V

době tvorby této

diplomové práce byla k

dispozici aktuální verze 3.5.0, která je
použita i v

rámci řešení této práce.





15

LGPL = Lesser General Public License. Svobodná licence pro šíření softwaru. Určena k

šíření dynamických
sdílených knihoven.

25


5.2 Tvorba výstupu


JasperReports produkuje výstup podle vstupní šab
lony, kter
á

je tvořen
a

souborem

s

příponou

.jrxml
.
Š
ablona obsahuje specifické elementy
popisující, co

bude kde umístěno a jaká data
mají být kam vložena. Tyto šablony
můžeme generovat ručně, nebo je

svěříme nástroji pro
tvorbu šablon zvaný
iReport.

Dalším krokem je kompilace takto vytvořené šablony. Vznikn
e tak soubor s

příponou

.jasper
,
který představuje serializovanou třídu, která vznikla ze vstupní šablony. A
plikace
následně použije vstupní šablonu, kterou naplníme parametry, datovou kolekcí
a dále ji buď
vytiskneme, nebo uložíme v

jednom z

možných soubo
rových formátů.




Obrázek
7
: Ze šablony na výstup


Vřele doporučujeme

ověřit si, zda pracujem
e se stejnou verzí jak nástroje
iReport
, tak
celé knihovny
JasperReports
, protože v

minulosti byla struktura šablony několikrát drobně
měněna a výsledná a
plikace používající kn
ihovnu ve spojení se šablonou by se mohla chovat
nedeterministicky.



5.3 Knihovny


Knihovna funkcí je k dispozici v aktuální verzi z

webových stránek projektu JasperReports
(2)

ve formě
ZIP

archivu.
Ten po dekompri
maci pomocí vhodného programu obsahuje kompletní
projekt se zdrojovými soubory a všemi potřebnými knihovnami, se kterým je možno nadále
pracovat například v

NetBeans

IDE.

26


C
elá distribuce zabírá diskový prostor přibližně 50MB,
což je
poc
hopitelně příliš
mnoho. P
ři využití všech zásadních vlastností

naštěstí potřebujeme

pouze zlomek
knihoven
,
která
distribu
ce

obsahuje:



commons
-
beanutils.jar



commons
-
collections.jar



commnos
-
digester.jar



commons
-
logging.jar



iText.jar



jdt
-
compiler.jar



poi.jar


V

naší aplikaci používáme pro podporu tisku knihovní modul
Jasper35Wrapper
, který
obsahuje výše zmíněné podpůrné knihovny a také poslední sestavenou distribuci ze
staženého ZIP archivu.


5.4 iReport


Hned v

úvodu stojí za zmínku zajímavost, že nástroj
iRep
ort

je od léta 2008 plně integrován do
vývojového prostředí
NetBeans

Platform, což je
n

dokazuje popularitu výše zmíněné
platformy.

Jak již bylo řečeno,
iReport

je nástroj pro snadnou tvorbu šablon. Obsahuje editor se
stránkou rozdělenou do několika
sekcí:



Title



titulek stránky. Zobrazuje se pouze na
první stránce.



Page Header



hlavička stránky. Zobrazuje se
v

záhlaví každé stránky.



Column Header



hlavička sekce
Detail
.
Zobrazuje se před sekcí detail na každé stránce.



Detail



hlavní obsah stránky. Zobrazuje
opakující se údaje datového zdroje, který právě
generuje.



Column Footer



patička sekce
Detail
. Zobrazuje
se po sekci detail na každé stránce.



Page Footer



patička stránky. Zobrazuje se
v

zápatí každé stránky.

27




Summary



sekce pro závěrečné součty a
shrnutí. Na sestavě se zobrazí před
Column
Footer
, bezprostředně za místem, kde končí tisk
sekce
Detail
.

Do příslušných

sekcí vkládáme komponenty

z panelu

Palette

metodou
Look
&
Feel
16
.
Mezi nejdůležitějšími stojí za zmínku např
íklad
TextField

pro
vkládání

dat při kompilaci
šablony,
Static Text

pro vkládání statických dat a další.

Jakmile rozmístíme a upravíme vzhled a tvar polí pro data, musíme specifikovat j
ejich
text, datový typ, optimálně

kódování pro PDF

formát
, jestli se bu
de zobrazovat
hodnota
nu
l
l
,

pokud nebudou data dodány apod.

Dále musíme nastavit datové objekty. Ty jsou trojího
druhu:



Parameter

(parametr)


tvar

$P{data}
.
Jednorázový parametr.
Při kompilaci předán
objektem

Map
<String, Object>
,

kde
kl
íč
em je

data

a hodnota
je
výslednou
hodnotou tohoto výrazu.



Field
(pole)


tvar

$F{data}
.

Prvek opakující
se datové kolekce objektů, která je zobrazována
v

sekci
Detail
. Atribut data je název funkce
objektu, ke kterému bude přistoupeno přes
GETTER
17

objektu, tedy
getData()
.



Variable

(proměnná)


tvar

$V{data
}
.

Zde se
nastavuje, co

se
má počítat
! Slouží k

tomu
atributy
variableExpression, Calculation
a

ResetType
.
U pole, které se odvolává na
proměnnou, je třeba nastavit, kdy má být
proměnná vyhodnocena.


Text
vizuálního objektu se musí shodovat s

některým předpisem pro dato
vý objekt.
V

panelu

Report Inspector

vytvořím
e přís
lušné datové elementy a nastavím
e shodn
ý typ
s

typem vizuální komponenty
, která

se na datový objekt odvolává.

Výsledek naší práce si můžem
e
prohlédnout přes záložku
Preview
.
Nástroj
automaticky vygeneruje zkompilovanou třídu s

příponou

.
jasper
.
Jakmile

vložím
e data pro
parametry,
vygeneruje
náhled
, který uvidím
e v

následném okně.




16

Look
& Feel = Metoda rozvrhov
ání vizuálních komponent tam kam chceme (Look), a jejího chování (Feel).

17

GETTER = metoda vracející hodnotu zapouzdřeného atributu třídy.

28


Doporučujeme
zkontrolovat,
zdali výsledná

sestava vypadá stejně
ve všech
poskytovaných
výstupních

formátech. PDF soubory jsou
citlivé na kódování, je nutné

nastavit
kódování CP1250
na všech objektech, jinak se mohou vyskytnout

problémy s

diakritikou.
Výstupní formáty jako HTML nebo XLS mají zase problémy s

překrýv
ající
mi se objekty.
Například soustava

textových polí ohran
ičena souvislým čtvercem nemusí být zobrazena.

Tento problém je pop

n na FAQ stránkách vydavatele

(3)
. Řešením je například

tyto objekty
obkreslit
soustavou čar, protože kompilátory

těchto formátů pracují
s
formulářem jako
se
soustavou
gridů
18
?á?•–‡”±?•‡?’⇕”ý˜ƒ–?•‡••À?á?Œ‹•ƒ•?•‡?•‡œ‘„”ƒœÀ?•’”ž˜•³?ä

Pro podrobnější informace o nástroji
iReport

doporučujeme

prostudovat
online zdroje,
viz

(2)
, (3)
.


5.5 Práce s

JasperReports API


5.5.1
Ko
mpilace a naplnění


Jak jsme si již popsal
i výše, kompilace je transformace

vstupní šablony s

příponou
.
jrxml

na
soubor s

příponou
.jasper
.
N
aplnění
je
pak vložením parametrů sestavy a datového zdroje
do zkompilovaného souboru:




Obrázek
8
: Naplnění zkompilované třídy daty





18

Grid = Čtvercový objekt.

29


Jak ukazuje obrázek, datový zdroj je definován pomocí interface

JRDataSource
,
definovaném v

balíku

net.sf.jasperreports.engine
.
Můžeme tedy datové rozhraní
implementovat sami a vytvořit si vlastní datový zdroj, nebo využít v

současnosti již 19
hotových implementací,
např.:



JRBeanCollectionDataSource



JREmptyDataSource



JRResultSetDataSource



JRTableModelDataSource



JRXmlDataSource


Tyto a další
implementace poskytují poměrně variabilní m
ožnosti práce s

datovými
zdroji

zahrnující
mi

práci s

kolekcemi,
výsledky

SQL dotazů, modely tabulek,
XML

soubory
apod. Za zajímavost stojí
datový zdroj

JREmptyDataSource
,

který je použit
, pokud
v

sest
avě nebude použita sekce
Detail
.

Ke kompilaci používáme třídu
JasperCompileManager
,
k

naplnění sestavy
parametry a datovým zdrojem zase

JasperFillManager
,
oba definované v

balíku
net.sf.jasperreports.engine
.

P
ři distribuci programu se můžeme rozhodnout, zda
budeme aplikaci distribuovat

s

nezkompilovanými šablonami a každá tvorba výstupu tuto šablonu zkompiluje, nebo
aplikaci dodávat se zkompilovanou šablonou a při tvorbě výstupu používat přímo tuto
šablonu.


5.
5.2 Výstup na tiskárnu


Nyní, když
sestavu
máme již naplněnou
, zbývá rozhodnout s
e, zda ji poslat
přímo
na

tiskárnu,
nebo vytvořit

okno s

náhledem vytvořené sestavy s

možností tisku nebo uložením do výše
uvedených výstupních formátů.

Pro možnost přímého ti
sku využijeme třídu

JasperPrintManager

z

balíku

net.sf.jasperreports.engine
,
pro zobrazení náhledu zase třídu

JasperViewer

z

balíku

net.sf.jasperreports.view
.



5.5.3 Výstup do souboru


30


V

mnoha manuálech a tutoriálech se uvádí použití třídy

JasperExportManager
z

balíku

net.sf.jasperreports.engine
,
ovšem
tato
třída umožňuje pouhé ukládání do formátu
PDF, HTML a XML
. Pokud bychom

chtěli ukládat jiné formáty, mu
seli bychom

používat
jejich
přímé implementace. Mnohem výhodnější je ale používání ro
zhraní

JRSaveContributor

z

balíku

net.sf.jasperreports.view.save

a
jeho známých implementací, které

ovládají
n
ízko
-
úrovňové

výstupní třídy samy. Jmenujme
například:



JRCsvSaveContributor



JRHtmlSaveContributor



JRPdfSaveContributor



JRRtfSaveContributor



JRMultipleSheetXlsSaveContributor


Pokud by se nám líbila možnost ukládání výstupu podobně jako přes náhled pro tisk
přes tlačítko pro uložení, kde se nám zobrazí okno pro uložení souboru do všech
podporovaných formátů, pak stojí za zmínku, že tato třída v
yužívá
těchto

JRSaveContributorů
.
Jejich hlavní výhodou je pouhé předání dvou parametrů při volání
metody
save
(…)
, tedy
parametry
naplněná sestava

a
výstupní soubor
. Pro inspiraci si můžem
e
prohlédnout zdrojový kód třídy

JRViewer

v

balíku

net.sf.jasperrep
orts.view
.



5.5.4 Praktická ukázka


Bill bill = getBill();

Collection<Item> items = bill.getItems();

Map<String, Object> params = getParams();

JRSaveContributor jrsc = new JRRtfSaveContributor

(Locale.getDefault(),

ResourceBundle.getBundle(„bundle“)
)
;

try

{


JasperReport jr = JasperCompileManager.compileReport(


„reports/bill.jrxml);

// zkompiluje šablonu



JasperPrint jp = JasperFillManager.fillReport(

jr, params, new

JRCollectionDataSource(items));





//
naplníme

již serializovanou třídu datovou kolekcí, parametry


Jasp
erViewer.viewReport(jp, false);

31





// náhled s

možností tisku či uložení do souboru


JasperPrintManager.printReport(jp, true);




// tisk s

možností výběru tiskárny


jrsc.save(jp, new File(„output.r
tf“));




// uložení do souboru output.rtf


} catch (JRException ex) {



System.err.println(ex.printStackTrace());


}


5.6
Závěr
em


Knihovna JasperReports spolu s

nástrojem iReport jsou opravdu šikovní pomocníci pro ty,
kteří chtějí, aby jejich aplik
ace podporovala výstup na tiskárnu nebo do výstupních souborů
různých
formátů
. Práce s

nimi je pohodlná a intuitivní. V

případě problémů
doporučujeme
prozkoumat
webové stránky vydavatele

(2)
, kde je dostupné
diskusní

fórum a také FAQ
stránky
,
viz
(3)
.













32


Kapitola 6

NetBeans Platform jako E
JB klient


Na první pohled se může zd
át, že propojit Enterprise Java
Beans s

NetBeans Platform nemůže
být nic složitého, ale opak je pravdou. Nedostatek dokum
entace i v

tomto případě situaci

ještě
více komplikuje. Mnohdy nezbývá, než se porozhlédnout po internetu a doufat, že najdeme
způsob, jak to udělat.

Naštěstí, jak ukázala například bakalářská práce pana Tomáše Vágnera napsaná
rovněž pod vedením Ing. Petra Adámka na FI MUNI v

roce
2007

(18)
, možnosti propojení
existují, nicméně jejich nastavování se ukazuje být komplikované.

V

době psaní této diplomové práce

je pod vedením Ing. Petra Adámka na FI MUNI
vyvíjena další bakalářská práce, tentokrát psaná panem Lukášem Krejčím

(20)
. Jejím cíl
em je
,

co možná nejvíce zjednodušit a automatizovat toto propo
jení. Protože jedním z

cílů

diplomové
práce bylo vyzkoušet a posoudit vhodnost rám
ce této bakalářské práce, museli jsme být
pravidelně v

kontaktu s

autorem a zkoušet

přírůstky na
vyvíjené
ukázko

aplikaci.
Bohužel,

mnohdy musel
pan Krejčí
postupovat zcela od začátku, když bylo jasné, že dorazil do slepé
uličky.

I tak v

této kapitole probereme všechny tři přístupy propojení klientské a aplikační
vrstvy chronologicky
,

dle vývoje tohoto aplikačního

rámce.

S
myslem jeho

bakalářské práce tedy bylo vytvořit rámec, který bude m
oct každý
programátor
použít

stejně jednoduše, jako když přes průvodce vytváříme třeba novou třídu.

Nyní ukážeme některé metody, které předcházely konečné verzi aplikačního rámce.
Tyto metody jsou rovněž funkční, ale nedosahují takové čistoty a obratnosti,
jak

bychom si
přáli.
Nakonec předvedeme finální verzi dostupnou v

době uzávěrky diplomových prací.
Jako
aplikační server byl použit
GlassFish V2
.


6.1
Úvodní verze


Úplně první verze propojení mezi EJB
a NetBeans Platform nepředstavuje nic nového.
V

podstatě ukazuje možnost
propojení

natvrdo
, která spočívala

ve vytvoření 2 modulů
sloužící
c
h

jako knihovny:



EJB
wrapper



v

něm je

uložen
JAR

archiv celé
aplikační vrstvy
.



JavaEEwrapper



obsahuje

soubor

javaee.jar

s

kompletní specifikací Java EE
.


33


Na těchto knihovnách musí

mít nastavenou závislost všechny moduly, které s

EJB
komunikují.

Dále byl modifikován soubor

project.properties
,

nacházející se ve složce
Important Files

klientské aplikace, konkrétně atribut
run.args.extra
:

run.args.extra=
-
J
-
da
-
cp:a
"C:/Program Files/glassfish
-
v2ur2/lib/



install/applications/jmsra/imqjmsra.jar";
\


"C:/Program Files/glassfish
-
v2ur2/lib/appserv
-
rt.jar";
\


"C:/Program
Files/glassfish
-
v2ur2/lib/appserv
-
ext.jar";
\


"C:/Program Files/glassfish
-
v2ur2/lib/appserv
-
admin.jar";
\


"C:/Program Files/glassfish
-
v2ur2/lib/appserv
-
ws.jar";
\


"C:/Program Files/glassfish
-
v2ur2/lib/appserv
-
deployment
-



client.jar";
\


"C:/Program File
s/glassfish
-
v2ur2/lib/javaee.jar";
\


"C:/Program Files/glassfish
-
v2ur2/lib/toplink
-
essentials.jar";
\

"D:/Diplomka/EJBContractz/dist/EJBContractz.jar"


Přidáním těchto knihoven manuálně na CLASSPATH
19

zajistíme, že aplikace bude ve
vývojovém prostředí fungov
at, ale ne mimo ni! Pozor je třeba dát si také na oddělovač
jednotlivých položek. Zde, pod OS Windows
,

je použit středník, ale pod Unixem je zde naopak
potřeba dvojtečka!

Soubor

EJBContractz.jar
,
zdrojový soubor
ukázkové
EJB vrstvy
aplikace, je
obsažen
také v

knihovním modulu EJBWrapper.

Soubor

imqjmsra.jar
,
appserv
-
admin.jar

a

appserv
-
ws.jar

slouží
k

podpoře Message
-
Driven Beans ukázkové aplikace.

Soubor

appserv
-
rt.jar
,
appserv
-
deployment
-
client.jar

a

appserv
-
ext.jar

obsahují
běhové prostředí aplikačníh
o serveru a nezbytné doplňkové knihovny.

Soubor

javaee.jar

obsahuje kompletní specifikaci
Java

EE a soubor


toplink
-
essentials.jar

je potřeba k

využití JPA.

Pokud bychom chtěli, aby b
yla aplikace takto napsaná funkční i mimo vývojové prostředí
NetBeans IDE
, musíme
zmíněné

knihovny kopírovat do složky

/
platformx/lib
,
nebo
umístit odkaz podobně jako v

souboru

project.properties
,
ovšem tentokrát ve složce

/etc

a

souboru

.conf
, například takto
:

default_options="
-
J
-
da
-
cp:a D:/Diplomka/Lib/jaspers.j
ar"




19

CLASSPATH = Při překladu či spouštění aplikace dáváme na vědomí překladači či zavaděči tříd, ve kterých
adresářích má začít hledat přeložené zdrojové kódy tříd po
třebných pro překlad či běh programů.

34


Práce uvnitř modulu probíhala následovně:

ctx = new InitialContext();

pr = (ProjectRemote) ctx.lookup(ProjectRemote.class.getName());


Tato verze sice
funguje, ale je to nevhodné

řešení.
Popírá veškeré výhody modularity,
každou distribuci je nutné
přenastavit v

souboru

.
conf

dané aplikace apod. N
icméně ve
stádiu vývoje
klientské aplikace se to ukázalo být dostatečným řešením.


6.2
Vývojová verze


Prvotní řešení propojení EJB s

NetBeans Platform z

praktického hlediska není vyhovující. Ani
zdaleka nev
yužíváme vlastností, které nám platforma poskytuje, což
můžeme

napravit
například vhodným používáním Filesystems API. Definujeme si soubor vlastností připojení, ke
kterému potom přistupujeme
, například takto
:

<filesystem>



<folder name="JNDI">



<folder name="GlassFish V2">


<folder name="glassfish">


<attr name="java.naming.factory.initial"
stringvalue="com.sun.enterprise.naming.SerialInitContextFactory"/>


<attr name="java.naming.factory.url.pkgs"

stringvalue="com.sun.enterprise.naming"/>


<attr name="java.naming.factory.state"
stringvalue="com.sun.corba.ee.impl.presentation.rmi.JNDIStateFacto
ryImpl"/>


<attr name="org.omg.CORBA.ORBInitialHost"
stringvalue="localhost"/
>


<attr name="org.omg.CORBA.ORBInitialPort"
stringvalue="3700"/>


</folder>


</folder>


</folder>

</filesystem>

35


Tato struktura je definována v

souboru

layer.xml
,
v

modulu nazvaném
GlassFishJNDIProperties
. Dále máme k

di
spozici
nový knihovní modul s

názvem
GFfiles
, který
obsahuje soubory

appserv
-
rt.jar, appserv
-
ext.jar, appserv
-
deployment
-
client.jar, jmxremote_optional.jar, javaee.jar
a

EJBContractz.jar.

Dál
e potřebujeme nainstalovat plugin

org
-
muni
-
ejbconnector.nbm
,
který
vyvinul právě Lukáš Krejčí. Po instalaci Vám
v

systémové nabídce
přibude wizard, který
vyvolám
e, p
okud vyberem
e akci
New

a potom komponentu
ServerConnector.java
. Po výběru
volby
ServerConnector.java

dokončíme wizard, přičemž ve zdrojovém kódu
při
bude

třída,
která využ
ije atributů souborového systému
, popsaného v

souboru

layer.xml

modulu
GlassishJNDIProperties
. Modul, ve kterém tedy vytvořím
e tuto třídu, musí být závislý jak na
modulu
GlassFishJNDIProperties
, tak
GFfiles
.


Předpokládejme
, že pomocí
wizardu vytvořím
e třídu
nazvanou
GlassFishConnector
.
Kód pro zpřístupnění Session Beans bude vypadat následovně:

ctx = new GlassFishConnector(„glassfish“).getInitialContext();

pr = (ProjectRemote) ctx.lookup(ProjectRemote.class.getName());

T
ato verze již využívá
možností Filesystems API, a především ze souboru
project.properties

zmizely všechny
parametry z

přepínače

run.args.extra
. Aplikace tak
fungovala bez jakýchkoliv dodatečných zásahů i mimo vývojové prostředí NetBeans IDE.

V

této


podobě

byla


definována


pouze

nastavení


pro


aplikační


server GlassFish
V2ur2, nicméně celkem bez problémů by šly atributy rozšířit i o podporu dalších aplikačních
serverů.


6.3
Konečná verze


Poslední a dle mého názoru nejjednodušší verze. Byla k

d
ispozici měsíc před termínem
odevzdání bakalářské práce Lukáše Krejčího s

tím, že již dále nebude měněna.

K

dispozici byla ve formě
kompletního zdrojového kódu. Podle mého
názoru při
náhledu do zdrojového kódu se jedná o zdařilé pokračování
předchozí
verze

s

tím, že

navíc
implementuje

konektory pro připojení k

dalším aplikačním serverům. V

současné verzi
k

těmto:



GlassFish V2



JBoss



WebSphere


36


Každá implementace aplikačního serveru vyžaduje tyto moduly:



Application Server Connector

(základní modul,
společný pro všechny aplikační servery)
.



Xxx AS Client Libraries

(potřebné knihovny pro
běh aplikačního serveru)
.



Xxx Connector

(vlastní implementace konektoru,
implementuje rozhraní modulu
Application

Server Connector
)
.


V

naší aplikaci
i nadále využíváme aplikační server
GlassFish V2
, takže potřebujeme
pouze moduly, vztahující se k

tomuto serveru
.

Postup sestavení spojení probíhá v

případě
aplikace
, která používá aplikační server
GlassFish V2

(případ naší ukázkové aplikace) takto:

1.

Sestavíme

moduly
Application Server Connector
,
GlassFish V2 AS Client Libraries

a
GlassFish V2
Connector
do 3 souborů s

příponou
NBM
.

2.

Tyto moduly nainstalujeme
d
o

vývojového
prostředí
.

3.

Ve vlastnostech naší aplikace
,

v komponentě

NetBeans Platform
Application
, na kartě
Libraries je nutno zatrhnout tyto tři moduly,
které se nachází v

uzlu extra.

4.

Vytvořím
e nový modul. V

jeho souboru

layer.xml

vytvoříme

popis hostitele a portu
připojení k

aplikačnímu serveru.
Struktura
souboru je
identická s

vývojovou

ver

s

tím
rozdílem, že obsahuje pouze atributy

org.omg.CORBA.ORBInitialHost
a

org.omg.CORBA.ORBInitialHost
.
T
oto
řešení bylo v

době konečné verze
nejvhodnější
,
protože tyto vlastnosti mohou být na různých
klientských počítačích různé. Popis je
v

dokumen
taci konektorů.

5.

Modul s

vlastnostmi

aplikačního serveru musí
mít nastavenou závislost na modulech, které
připojení k

aplikačnímu serveru využívají.

6.

Modul, který využívá připojení k

aplikačnímu
serveru, musí mít nastavenou závislost na
importovaném modulu
A
pplication Server
Connector
.
Implementace je volána automaticky,
impl
ementuje
totiž potřebná rozhraní, která si
37


rovněž zaregistrovala v

META
-
INF balíku svého
modulu.

7.

Dále již pracujeme s

třídou ApplicationServer.


6.3.1
Ukázka

souboru layer.xml


<?xml vers
ion="1.0" encoding="UTF
-
8"?>

<!DOCTYPE filesystem PUBLIC "
-
//NetBeans//DTD Filesystem 1.1//EN"
"http://www.netbeans.org/dtds/filesystem
-
1_1.dtd">

<filesystem>



<folder name="JNDI">


<folder name="GlassFishV2">


<file name="glassfish">


<attr name="org.omg.CORBA.ORBInitialHost"



stringvalue="localhost"/>


<attr name="org.omg.CORBA.ORBInitialPort"



stringvalue="3700"/>


</file>


</f
older>


</folder>

</filesystem>


6.3.2 Ukázka připojení ke kontextu


Context ctx;


ApplicationServer appServ
er
;

appServer = new ApplicationServer(ApplicationServer.GlassFishV2,
"glassfish");

ctx = appServer.getInitialContext();


Oproti vývojové verzi

nám tedy ubyla práce s

tvorbou wizardu pro konektor serveru a ubyl
modul
GFiles
, ve kterém se nacházely podpůrné knihovny pro správu připojení mezi
klientskou a aplikační vrstvou
,

a knihovnu s

EJB

vrstvou
aplikace. Tyto knihovny jsou totiž
obsaženy v