<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>SAGES:: Blog &#187; Jakub Koperwas</title>
	<atom:link href="http://blog.sages.com.pl/author/jkoperwas/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.sages.com.pl</link>
	<description>Blog konsultantów firmy Sages - artykuły o technologiach Java EE i pokrewnych</description>
	<lastBuildDate>Mon, 13 Jun 2011 15:50:18 +0000</lastBuildDate>
	
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Confitura 2011 &#8211; wrażenia</title>
		<link>http://blog.sages.com.pl/2011/06/confitura-2011-wrazenia/</link>
		<comments>http://blog.sages.com.pl/2011/06/confitura-2011-wrazenia/#comments</comments>
		<pubDate>Mon, 13 Jun 2011 15:50:18 +0000</pubDate>
		<dc:creator>Jakub Koperwas</dc:creator>
				<category><![CDATA[Bez kategorii]]></category>
		<category><![CDATA[confitura]]></category>
		<category><![CDATA[javarsovia]]></category>

		<guid isPermaLink="false">http://blog.sages.com.pl/?p=138</guid>
		<description><![CDATA[Wrażenia po tegorocznej Confiturze
W sobotę miałem przyjemność występować jako prelegent i przedstawiciel sponsora na konferencji Confitura (dawniej Javarsovia).
Ogólnie lubię konferencje, na których ludzie faktycznie chcą się czegoś dowiedzieć. Bardzo mi było miło że salę miałem pełniutką &#8211; mam tylko nadzieje, że dla większości z audytorium nie był to czas stracony, ale nie mnie oceniać.
Co do [...]]]></description>
			<content:encoded><![CDATA[<p>Wrażenia po tegorocznej Confiturze</p>
<p>W sobotę miałem przyjemność występować jako prelegent i przedstawiciel sponsora na konferencji Confitura (dawniej Javarsovia).</p>
<p>Ogólnie lubię konferencje, na których ludzie faktycznie chcą się czegoś dowiedzieć. Bardzo mi było miło że salę miałem pełniutką &#8211; mam tylko nadzieje, że dla większości z audytorium nie był to czas stracony, ale nie mnie oceniać.</p>
<p>Co do innych, udałem się na następujące prezentacje:</p>
<p>Patrycja Wegrzynowicz &#8211; Patterns and Anti-Patterns in Hibernate<br />
Dla mnie temat świetny. Lubię &#8220;caveatsy&#8221;, a Patrycja zna je świetnie i potrafi je wyłuszczyć. Ma świetny kontakt z ludźmi, nadto podzielam Jej pogląd, że w tej branży nie wolno się zwalniać z obowiązku  myślenia i polegać na &#8220;autorytetach&#8221;.  Jedyne &#8220;ale&#8221; to takie, że ja chciałbym mieć więcej treści nawet kosztem tego, że prelegent je poda na slajdzie i wytłumaczy a nie pozwoli samemu do tego dojść. Słowem &#8211; jak mam przed sobą eksperta to chcę wydusić z niego ile się da.</p>
<p>Tomasz Kopacz &#8211; Quo Vadis IT<br />
Zadziwiło mnie nieliczne audytorium. Wykładu nie da się streścić, to trzeba wysłuchać. Tomek ma świetny dystans &#8211; jest na tyle ogólny by zobaczyć coś więcej niż linijki kodu, a zarazem z jego prezentacji można wyciągnąć wiele inspiracji czy konkretnych wręcz pomysłów. Wielki szacun!</p>
<p>Paweł Lipiński &#8211; Re-fuck-toryzacja czyli sprowadzanie sp****go kodu na właściwe tory.<br />
Cóż, wielka osobowość, prawdziwe show. Szkoda tylko, że sala była zbyt wielka i nie widziałem dobrze kodu. Trudno mi się w związku z tym odnieść do prezentacji bardziej merytorycznie, bo siedziałem zbyt daleko &#8211; frekwencji za to tylko pozazdrościć.</p>
<p>Adam Warski &#8211; Manipulacja beanami, czyli CDI Portable Extensions &#8211; Tu będę nieobiektywny &#8211; bo się trochę na temacie znam więc z informacji &#8220;jak to się robi&#8221; nie skorzystałem, bo wiem, a za to mam zastrzeżenia do przykładów Adama. Wydaję mi się ze Seam Security ma trochę więcej możliwości, niż rozwiązanie autorskie (lub firmowe &#8211; nie pamiętam) Adama. Rozumiem jednak, że CDI jest ciągle nie tak popularne, jak na to moim zdaniem zasługuje i Adam nie mógł polecieć za ambitnie.</p>
<p>Jacek Lis &#8211; Zdarzenia rządzą światem &#8211; jak sobie z nimi radzić? &#8211; To chyba jest mój nr jeden, temat w zasadzie mi znany, ale sposób prezentacji pozwalał jeszcze raz systematycznie sobie tą wiedzę uporządkować. Mimo iż w tym przypadku nie było wielkiego show to dla odmiany była wysoka skuteczność w przekazie wiedzy. Nadto Jacek sprawiał wrażenie jakby temat nie był &#8220;wydumany&#8221; przez autora, tylko był naturalną konsekwencją tego, co Jacek na co dzień spotyka w pracy.</p>
<p>To by było na tyle przemyśleń. Zobaczymy co za rok.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.sages.com.pl/2011/06/confitura-2011-wrazenia/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Lekkie aplikacje internetowe z wykorzystaniem Java Enterprise Edition w wersji 6</title>
		<link>http://blog.sages.com.pl/2010/06/lekkie-aplikacje-internetowe-z-wykorzystaniem-java-enterprise-edition-w-wersji-6/</link>
		<comments>http://blog.sages.com.pl/2010/06/lekkie-aplikacje-internetowe-z-wykorzystaniem-java-enterprise-edition-w-wersji-6/#comments</comments>
		<pubDate>Wed, 02 Jun 2010 20:29:14 +0000</pubDate>
		<dc:creator>Jakub Koperwas</dc:creator>
				<category><![CDATA[Problemy i rozwiązania]]></category>
		<category><![CDATA[EJB3.1]]></category>
		<category><![CDATA[JEE6]]></category>

		<guid isPermaLink="false">http://blog.sages.com.pl/?p=51</guid>
		<description><![CDATA[JEE 6 czas zacząć
Niniejszym wątkiem o prowokującym tytule otwieram cykl postów dotyczących Java Enterprise Edition w wersji 6 (JSR 316).
Po dłuższym namyśle postanowiłem nie zaczynać od przeglądu całej JEE6, ani też podejmować się jej subiektywnej oceny, a tym samym nie wpisywać się w polemikę w stylu: „czy lepszy czasem kulejący standard czy super przemyślany nie-standard”. [...]]]></description>
			<content:encoded><![CDATA[<h1>JEE 6 czas zacząć</h1>
<div id="_mcePaste">Niniejszym wątkiem o prowokującym tytule otwieram cykl postów dotyczących Java Enterprise Edition w wersji 6 (JSR 316).</div>
<div id="_mcePaste">Po dłuższym namyśle postanowiłem nie zaczynać od przeglądu całej JEE6, ani też podejmować się jej subiektywnej oceny, a tym samym nie wpisywać się w polemikę w stylu: „czy lepszy czasem kulejący standard czy super przemyślany nie-standard”. Skupię się na faktach, nowościach, zmianach i co najwyżej subiektywnych odczuciach, dotyczących „trendów”.</div>
<div><span id="more-51"></span></div>
<div id="_mcePaste">To, co można powiedzieć bezsprzecznie, nie narażając się na bycie kontrowersyjnym, to to że w JEE6 trochę się zmieniło. Ci, którzy do tej pory tworzyli aplikacje w JEE5 i obserwowali pewne kłopotliwe braki w specyfikacjach – czasem duże, jak np. brak criteria API w JPA1, czy drobne: niemożność automatycznego startowania usług czasowych w EJB 3.0 &#8211; odczują prawdopodobnie poprawę komfortu pracy. Ci, którzy korzystali do tej pory ze szkieletów typu Seam z przyjemnością odkryją, że spora część Seam’a z jego kontekstami, wstrzykiwaniem zależności, zasięgiem konwersacji, czy rozgłaszaniem i konsumowaniem zdarzeń przez komponenty zostały wciągnięte do standardu mocą specyfikacji Context and Dependency Injection for Java EE (JSR 299) i Dependency Injection for Java (JSR 330). Optymizmem napawa również fakt, iż niektóre składowe specyfikacji trzymane dla zgodności z poprzednimi wersjami, zostały oznaczone jako możliwe do usunięcia w kolejnych wersjach – sama główna specyfikacja EJB 3.1 to ponad 600 stron opisująca nawet takie starocie jak EJB 1.1 Entity Bean – najwyższy czas już posprzątać.</div>
<h1>Lekkie aplikacje w JEE i to bez dodatkowych szkieletów?</h1>
<div id="_mcePaste">Na omawianie poszczególnych ”ficzerów” JEE6 przyjdzie pora przy omawianiu konkretnych specyfikacji, tu chciałbym rozważyć pewien kierunek zapoczątkowany przez JEE5 a mocno rozwinięty w JEE6, który powoli zrywa z konotacją JEE = „ciężka aplikacja”, w opozycji do np. „lekkich szkieletów”.</div>
<div id="_mcePaste">Historycznie aplikacja JEE wykorzystująca EJB kojarzyła się raczej z aplikacją posiadającą wydzieloną warstwę logiki biznesowej, w szczególności dostępnej zdalnie, w opozycji do podejścia opartego na wyłącznie komponentach webowych, z logiką umieszczoną w POJO (Plain Old Java Objects), czyli w zwyczajnych obiektach javowych. Zwykle też nie obyłoby się bez wsparcia wszelakich szkieletów umożliwiających Inversion of Controll/Dependency Injection jak np. Spring, czy SEAM, zwłaszcza gdy nie używamy EJB i nie mamy możliwości użycia transakcji zarządzanej przez kontener (CMT), deklaratywnego zabezpieczania zasobów etc.</div>
<div id="_mcePaste">Aktualna formuła Java EE 6 stara się objąć standardem tworzenie zarówno „ciężkich”, jak i „lekkich aplikacji”, w taki sposób, aby dało się je pisać bez konieczności korzystania z dodatkowych szkieletów spoza standardu.</div>
<div id="_mcePaste">Powyższe stwierdzenie opieram na następujących zmianach, które zaobserwowałem:</div>
<h3>Wprowadzenie koncepcji Komponentu Zarządzanego (Managed Bean &#8211; dalej MB)</h3>
<div id="_mcePaste">Wiele szkieletów reklamuje się jako opartych na POJO. Nie jest jednak to pojęcie zdefiniowane formalnie. Jeśli potraktujemy POJO dosłownie (Zwyczajny Obiekt Java), czyli interpretując jako obiekt, który nie jest zarządzany przez żaden kontener i nie posiada konfiguracji, wówczas ciężko jest przyznać rację wielu szkieletom które chwalą się, że oparte są na POJO, ale np. wymagają uprzedniego skonfigurowania w XMLu, czy anotacjach po to, ażeby działo wstrzeliwanie zależności, czy transakcje (patrz http://en.wikipedia.org/wiki/Plain_Old_Java_Object).</div>
<div id="_mcePaste">W takim kontekście POJO rozumiane było raczej jako nie-EJB, co prawdopodobnie zgodne jest z pierwotną intencją twórcy pojęcia, Martina Fowlera (http://www.martinfowler.com/bliki/POJO.html).</div>
<div id="_mcePaste">JEE 6 „definiuje” lub „zawłaszcza” (w zależności od poglądów) to pojęcie w specyfikacji Managed Beans 1.0, która jest wydzieloną częścią głównej specyfikacji JEE6. Cytując za specyfikacją:</div>
<div id="_mcePaste">„Komponent Zarządzany (Managed Bean) jest zarządzanym przez kontener obiektem, znanym jako skrót POJO, który spełnia minimalny zestaw wymogów.”</div>
<div id="_mcePaste">W telegraficznym skrócie: MB jest oznaczony specjalną anotacją, może posiadać nazwę widoczną w JNDI i określony cykl życia, który jest zarządzany przez kontener. Nie ma tu słowa o bardziej zaawansowanych elementach, które np. posiadają EJB.</div>
<div id="_mcePaste">Managed Bean jest pojęciem wspólnym, wykorzystywanym dalej przez inne specyfikacje (EJB, JSF) które mogą na te wymagania wpływać. Szczegóły wymagań dla MB poznamy w załączniku.</div>
<h3 id="_mcePaste">Wyodrębnienie specyfikacji Interceptors</h3>
<div id="_mcePaste">Specyfikacja Interceptorów (Przechwytywaczy), została wyodrębniona w obrębie specyfikacji EJB i może być wykorzystywana ze wspomnianymi wcześniej Komponentami Zarządzanymi, dodając elementy aspektowości do programowania w JEE. Dla przypomnienia: Interceptor potrafi przechwycić wołanie metody komponentu, powodując wykonanie własnego kodu, który może np. zmodyfikować parametry wołania etc.</div>
<h3 id="_mcePaste">Wprowadzenie możliwości wstrzykiwania zależności (Dependency Injction)</h3>
<div id="_mcePaste">W JEE5 pojawiły się pierwsze próby podejścia do problemu – w postaci anotacji @EJB, @Resource, @WebserviceRef, potrafiące wstrzyknąć zależność będącą komponentem EJB, zasobem JCA czy odwołaniem do usługi Webservice. Wstrzykiwanie było możliwe do ściśle określonych miejsc: komponentu EJB, servletu, komponentu zarządzanego JSF, etc.</div>
<div id="_mcePaste">Mocą specyfikacji Context and Dependency Injection for Java EE (JSR 299) większość klas Java, a w szczególności wszystkie Java Beans są komponentami zarządzanymi (MB), a do wszystkich komponentów zarządzanych stosują się mechanizmy wstrzykiwania zależności. Szczegóły poznamy w innych postach, warto tylko zauważyć że wstrzykiwanie zależności dostępne jest teraz niemal dla każdego możliwego obiektu.</div>
<h3 id="_mcePaste">Wprowadzenie kontekstów</h3>
<div id="_mcePaste">Wymieniona wyżej specyfikacja JSR 299 umożliwia również umieszczanie komponentów w kontekstach, które determinują ich cykl życia. Do tej pory możliwość sterowania długością życia komponentów zarządzanych (JEE, Spring) był ograniczony: komponenty mogły być albo tworzone ad hoc dla każdego żądania, albo trwać w całej rozciągłości sesji lub też aplikacji. Seam  wprowadził nowy zasięg konwersacji, którego długość życia określana jest przez programistę. Specyfikacja CDI wciela tę możliwość do JEE6, dając bardzo potężne narzędzie do żonglowania komponentami w obrębie aplikacji.</div>
<div id="_mcePaste">Gdyby na tym poprzestać to rysuje nam się widok aplikacji opartej na prawie zwyczajnych klasach, ze wsparciem dla wstrzykiwania zależności, kontekstowości i przechwytywania wołań. Ale pójdziemy jeszcze dalej, włączymy w to „lekkie EJB” (brzmi jak margaryna o smaku masła, ale mimo wszystko o dziwo smakuje)</div>
<div id="_mcePaste">
<h3>Umożliwienie użycia EJB w „lżejszych” scenariuszach z zachowaniem podstawowych możliwości, poprzez</h3>
<ul>
<li> wprowadzenie lekkiej wersji EJB, pozwalającej jedynie na dostęp lokalny, pozbawionej MDB, czy usług czasowych (więcej w dodatku i innych postach)</li>
<li> wprowadzenie bezinterfejsowych EJB, które już coraz bardziej przypominają POJO</li>
<li> wprowadzenie kontenera „embeddable”, czyli lekkiego kontenera zagnieżdżanego w aplikacjach Java SE, pozwalającego na użycie tamże komponentów EJB</li>
<li> możliwość wdrażania EJB jako moduł war (czyli jako część aplikacji webowej</li>
</ul>
</div>
<div>Tym sposobem podstawowe funkcjonalności EJB, takie jak deklaratywne zabezpieczanie zasobów, czy transakcje zarządzane przez kontener zasilają możliwości naszych Komponentów Zarządzanych, nie pociągając za sobą konieczności używania „całej armaty”, np. z dostępem zdalnym i innymi funkcjonalnościami, nie zawsze potrzebnymi w prostej aplikacji, a całą aplikację możemy zapakować w wara.</div>
<div id="_mcePaste">Całość przypieczętowuje pojęcie profilu</div>
<h3 id="_mcePaste">Wprowadzenie koncepcji profilu</h3>
<div id="_mcePaste">Profil to, cytując za specyfikacją: „konfiguracja Platformy JEE, nakierowana na konkretną klasę aplikacji” (klasę w rozumieniu rodzaju).  Do tej pory mówiliśmy o Serwerach aplikacji które musiały wspierać całą JEE oraz o Serwerach Webowych, które adresowały lekkie aplikacje webowe  takich jak np. Tomcat. Serwery webowe wspierały pewien wybrany zbiór specyfikacji np. Servlet/JSP/JSF.. Pojęcie serwera webowego nie było jednak sprecyzowane w  szczególności nie istniała lista specyfikacji którą powinien implementować serwer webowy. W JEE6 wprowadzony zostaje tzw. „Web Profile” czyli zestaw specyfikacji które powinien zawierać serwer webowy. W skład Web Profile w  szczególności wchodzą specyfikacje Servlet, JSP, JSF, ale także  EJB Lite i JTA. A więc komponenty EJB będą od teraz mogły działać na serwerach typu Web, a nie tylko pełnych serwerach aplikacji. Cały Web Profile opisany jest w dodatku.</div>
<h1>Co dalej?</h1>
<div id="_mcePaste">W kolejnych postach zechcę przybliżyć jedynie to, co w JEE6 nowe lub zmienione, nie zaś omawiać ją krok po kroku. Postaram się jednak żeby posty zrozumiałe były również dla początkujących w JEE6. Zacznę od omówienia zmian w specyfikacji EJB 3.1 i JPA 2.0. Postaram się także z bliska pokazać jak w praktyce udaje się tworzyć „lekkie” aplikacje oparte w całości na JEE6.</div>
<h2>DODATEK 1 – Wymagania Specyfikacji Managed Beans.</h2>
<div>Na podstawie dokumentu <em>Managed Beans 1.0 Specification</em> będącego częścią  <em>Java TM Platform, Enterprise Edition 6 (Java EE 6) Specification (JSR 316 )</em></div>
<h3>Wymagania podstawowe:</h3>
<div id="_mcePaste">o	Definiowanie Komponentu Zarządzanego: jest to klasa konkretna, rozszerzalna (nie abstract, nie final), nie będąca wewnętrzną klasą statyczną; Komponent Zarządzany oznaczony jest anotacją javax.annotation.ManagedBean. W wersji podstawowej ziarno powinno posiadać konstruktor bezargumentowy</div>
<div id="_mcePaste">o	Nazewnictwo: Komponent zarządzany może mieć nazwę podaną w anotacji @ManagedBean(“myName“), nawzwa musi być unikalna w obrębie modułu. Nazwanie Komponentu pociąga możliwość wyszukania go w przestrzeni nazw JNDI pod nazwami:</div>
<div id="_mcePaste">java:app/&lt;module-name&gt;/&lt;bean-name&gt; – dla przestzeni nazw aplikacji oraz</div>
<div id="_mcePaste">java:module/&lt;bean-name&gt; &#8211; dla przestrzeni nazw modułu</div>
<div id="_mcePaste">o	Cykl życia i zasoby</div>
<div id="_mcePaste">Ziarna mogą korzystać z metod oznaczonych javax.annotation.PostConstruct i javax.annotation.PreDestroy do wskazania metod wołanych przez kontener po utworzeniu i przed zniszczeniem Ziarna.</div>
<div id="_mcePaste">Komponenty zarządzane w ogólności nie mają własnej przestrzeni nazw( tak jak np. EJB), zasoby z których korzystają powinny się znaleźć w przestrzeni modułu</div>
<div id="_mcePaste">o	Wątki</div>
<div id="_mcePaste">Metoda ziarna wykonywana jest w tym samym wątku co wołający</div>
<div id="_mcePaste">o	Interceptory</div>
<div id="_mcePaste">MB mogą używać interceptorów zdefiniowanych w specyfikacji Interceptors 1.1</div>
<div>Przykład Komponentu Zarządzanego:</div>
<p><code><br />
@ManagedBean(“myName“),<br />
public class MyClass{</code></p>
<p>@PostConstruct<br />
public void init(){}</p>
<p>@PreDestroy<br />
public void destroy(){};</p>
<p>//inne metody</p>
<p>}</p>
<div id="_mcePaste">Jest komponentem zarządzanym i widoczny w przestrzeni nazw  JNDI  dal modułu jako</div>
<div id="_mcePaste">java:module/myName</div>
<div id="_mcePaste">Komponent definiuje również metodę wołanych przy tworzeniu i niszczeniu Komponentu.</div>
<h3>Rozszerzenie wymagań:</h3>
<div id="_mcePaste">Wymagania podane w specyfikacji mogą być zmieniane w specyfikacjach bazujących na powyższej w następujący sposób</div>
<div id="_mcePaste">•	Definiowanie Komponentu Zarządzanego: specyfikacja rozszerzająca może podać inne sposoby definiowania komponentu , w szczególności dołożyć wsparcie dla konstruktorów z argumentami, niwelując konieczność deklarowania konstruktora bezargumentowego</div>
<div id="_mcePaste">•	nazewnictwo: specyfikacja rozszerzająca może podać inny sposób nazywania MB – np. poprzez dodatkowe anotacje, jednakże jeśli istnieje anotacja @ManagedBean(”&#8230;”) to ma ona zawsze pierwszeństwo. Spec. rozszerzająca może również wprowadzać dodatkowe przestrzenie nazw lub też nazwy alternatywne dla ziarna</div>
<div id="_mcePaste">•	cykl życia i zasoby,</div>
<div id="_mcePaste">Spec Roz może definiować bardziej skomplikowany cykl życia a także wprowadzić przestrzeń nazw dla komponentu “java:comp”</div>
<div id="_mcePaste">•	wątki : specyfikacja może anulować wymaganie na konieczność wołania w wątku wołającego</div>
<div id="_mcePaste">•	Interceptory specyfikacja może udostępniać dodatkowy mechanizmy interceptorów niż podane w sepcyfikacji</div>
<h2>DODATEK 2 – Lista specyfikacja wymagana dla serwera umożliwiającego udostępnianie aplikacji zgodnej z Web Profile</h2>
<div>Na postawie <em>Java™ Platform, Enterprise Edition 6 (Java EE 6) Web Profile Specification CHAPTER WP.2 Web Profile Definition</em> będącego częścią <em> JavaTM Platform, Enterprise Edition 6 (Java EE 6) Specification (JSR 316 )</em></div>
<div><em><br />
</em></div>
<div id="_mcePaste">o	Servlet 3.0</div>
<div id="_mcePaste">o	JavaServer Pages (JSP) 2.2</div>
<div id="_mcePaste">o	Expression Language (EL) 2.2</div>
<div id="_mcePaste">o	Debugging Support for Other Languages (JSR-45) 1.0</div>
<div id="_mcePaste">o	Standard Tag Library for JavaServer Pages (JSTL) 1.2</div>
<div id="_mcePaste">o	JavaServer Faces (JSF) 2.0</div>
<div id="_mcePaste">o	Common Annotations for theJava Platform (JSR-250) 1.1</div>
<div id="_mcePaste">o	Enterprise JavaBeans (EJB) 3.1 Lite</div>
<div id="_mcePaste">o	Java Transaction API (JTA) 1.1</div>
<div id="_mcePaste">o	Java Persistence API (JPA) 2.0</div>
<div id="_mcePaste">o	Bean Validation 1.0</div>
<div id="_mcePaste">o	Managed Beans 1.0</div>
<div id="_mcePaste">o	Interceptors 1.1</div>
<div id="_mcePaste">o	Contexts and Dependency Injection for the Java EE Platform 1.0</div>
<div id="_mcePaste">o	Dependency Injection for Java 1.0</div>
<h2>DODATEK 3 – EJB vs. EJB Light</h2>
<div>Na podstawie dokumentu  <em>JSR 318: Enterprise JavaBeansTM,Version 3.1EJB Core Contracts and Requirements chapter 21.1  EJB 3.1 Lite</em></div>
<div id="_mcePaste">
<table border="1" cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td width="205" valign="top"></td>
<td width="205" valign="top">EJB Light</td>
<td width="205" valign="top">Pełne EJB</td>
</tr>
<tr>
<td width="205" valign="top">Komponenty sesyjne</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Komponenty   sterowane wiadomością</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Komponenty   Encyjne zgodne z EJB 2.x/1.x</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK, oznaczone   do usunięcia w przyszłych specyfikacjach</td>
</tr>
<tr>
<td width="205" valign="top">JPA 2.0</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Dostęp lokalny   i bez-interffejsowy</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Dostęp zdalny   zgodny z EJB 3.0</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Dostęp zdalny   zgodny z EJB 2.x</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Dostep przez   JAX-WS</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Dostęp przez   JAX-RPC</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK, oznaczone   do usunięcia w przyszłych specyfikacjach</td>
</tr>
<tr>
<td width="205" valign="top">Usługa czasowa   (Timer Service)</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Wołanie   asynchroniczne komponentów sesyjnych</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Interceptory</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Zgodność z RMI-IIOP</td>
<td width="205" valign="top">NIE</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Transakcje   zarządzane przez kontener/komponent (CMT i BMT)</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">Deklaratywne i   programistyczne zabezpieczanie komponentów</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK</td>
</tr>
<tr>
<td width="205" valign="top">API kontenera zagnieżdżonego</td>
<td width="205" valign="top">TAK</td>
<td width="205" valign="top">TAK, ale jeśli   serwer dostarcza pełnego EJB to API dla kontenera zagnieżdżonego może   ograniczać się jedynie do zestawu Light</td>
</tr>
</tbody>
</table>
</div>
]]></content:encoded>
			<wfw:commentRss>http://blog.sages.com.pl/2010/06/lekkie-aplikacje-internetowe-z-wykorzystaniem-java-enterprise-edition-w-wersji-6/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

