Chciałbym zaznaczyć, że nie powinniście traktować tych opisów jako wiedzy technicznej. Nie polegajcie na tym co tu piszę w 100%, zawsze sprawdzajcie szczegóły. Ogólnie jest tak jak piszę, ale nie gwarantuję, że wszystkie kody są w 100% kompilowane i poprawne. Mają tylko demonstrować ideę jaką chcę przekazać.
Pora na EJB
Zastanawiałem się, czy wyróżnić tę część J2EE, ale ostatecznie jest tu chyba największa analogia do środowiska COM/DCOM i warto chwilę o tym napisać.
No więc dla zrozumienia idei możecie przyjąć, że EJB i COM to jest kropka w kropkę to samo. Tylko, że oczywiście EJB są bardziej przejrzyste i jakoś wszystko jest do zapisania prawie w samej javie (no i trochę XML). Nie wypowiem się o tym jak się stawia do tego środowisko i takie tam... bo to jak już pisałem zazwyczaj będziecie mieli gotowe. A nawet jeśli miałby was ktoś o to zapytać, to zawsze możecie powiedzieć, że stawiał to admin, a wy tylko developowaliście.
To co zauważyłem, to że zazwyczaj bean składa się z co najmniej dwóch plików w javie. Pierwszy zawiera definicję interfejsu (czyli puste metody). Ten plik zazwyczaj nazywa się tak samo jak klasa komponentu/serwisu. Drugi plik, gdzie już implementowany jest interfejs ma taką samą nazwę (klasę) z sufiksem Impl. Czyli mamy tak:
// plik MyComponent.java
// przykładowa deklaracja
public interface MyComponent {
public String myMethod(...);
...
}
// plik MyComponentImpl.java
// przykładowa implementacja
public class MyComponentImpl implements MyComponent {
public String myMethod(...) {
...
}
...
}
W środowisku J2EE przyjęło się jakoś nazywać te komponenty serwisami. Być może jest to jakiś lokalny zwyczaj jaki poznałem i dotyczy tylko komponentów bezstanowych. W tym przypadku nazywanie komponentu serwisem ma dość duże uzasadnienie - podobnie jak klasę statyczną można nazywać biblioteką funkcji.Kolejnym krokiem jest osadzenie naszego serwisu na jakimś hoście... czyli serwerze aplikacji, czy jak to tam nazwać. Jak wiecie w COM komponenty też same nie działały. Musiały posiadać aplikację hosta, która komponenty tworzyła, puszczała w procesie (najczęściej osobnym na każdy pakiet) i zapewniała komunikację ze światem (i z komponentami między sobą). W przypadku COM tym hostem był MTS.
W EJB mamy jakiś wybór bo sama technologia jest ogólnodostępna i jest kilka implementacji... Ja miałem okazję zapoznać się z jedną w prostszych - Spring. Na 100% nie powiem czy to tylko framework czy host dla aplikacji, w każdym razie jest to kolejna warstwa, którą musimy pokonać w czasie implementowania serwisu/komponentu. Spring przyjmuje informacje o naszym komponencie w postaci pliku XML. Wygląda on jakoś następująco:
<bean class="com.mycom.myController" id="myController"> <property name="myComponent" ref="myComponent"> </property> </bean>W praktyce, jeśli trafi się wam zadanie aktualizacji jakiegoś serwisu czy dopisania do niego jednej metody, to powinniście operować w obrębie tych trzech plików.
Jeśli traficie do projektu, który już istnieje i wszystko ma skonfigurowane, to myślę, że będą wam wdzięczni, że nic więcej nie będziecie zmieniać. Z reguły (podobnie jak to miał Granit) istnieją już jakieś klasy bazowe, które załatwiają detale techniczne i w zasadzie pozostaje już programowanie czysto biznesowe.
Dużym sprzymierzeńcem jest tu środowisko. W Eclipse wciskam CTRL+SHIFT+R i otwiera się okienko wyszukiwania wszystkich składowych projektu. W ten sposób łatwo zlokalizujemy klasę wg nazwy - zarówno jej interfejs jak i implementację.
Kolejnym sprzymierzeńcem jest sam język, który w kolejnych wersjach wchłania co bardziej powszechne rozwiązania i ułatwia ich stosowanie. Tak na przykład jest w korzystaniu z serwisów. Wcześniej każda klasa wymagała też rozbudowywania pliku XML po stronie klienta, obecnie java potrafi to wspomagać. A co za tym idzie robota programisty korzystającego z beana jest prostsza:
@Autowired myComponent mc;Jest jeszcze jedna ważna rzecz o jakiej chciałbym przypomnieć.
Każda technologia ma polecane metody komunikacji i przeznaczone do tego typy danych itp. Podobnie jest też w przypadku bean'ów. Najczęściej korzysta się tu z tzw. serializacji - czyli zamiany obiektu klasy na strumień bitów. Przesyłane powinny być tylko obiekty klas implementujących interfejs serializable. Gdzieś wspominałem, że warto z tym się zapoznać i chyba na wszystkich rozmowach kwalifikacyjnych o to pytają.
Podobnie miał zresztą COM, ale nie wiadomo czemu na którymś z etapów rozwoju postanowiono całą komunikację ograniczyć od tablic OleVariant - myślę, że to największa zmora z jaką przyszło spotykać się ProgramiścieGranit. Tu na szczęście jest łatwiej, a na wszystkie problemy potrafi odpowiedzieć google ;)
Myślę, że na początek tak powierzchowna wiedza wam wystarczy. Zainteresowani więcej znajdą w internecie.
W kolejnym kroku będę chciał coś wspomnieć o JPA i Hibernate...
Zamieszczone przykłady pochodzą ze strony: http://static.springsource.org/spring/docs/1.2.7/reference/ejb.html
Brak komentarzy:
Prześlij komentarz