KoziołekWeb

Dziś będziemy dodawać bazę danych, a właściwie „bazę danych” do naszego projektu. Jest to całkiem dobry moment by przyjrzeć się skąd JLNS zaczyna wyliczać classpath.

Baza danych

Niekoniecznie relacyjna. Wielokrotnie spotkałem się z niezrozumieniem ze strony poganiaczy w dziedzinie składowania danych. Architekci przy wsparciu managerów zazwyczaj forsują rozwiązania relacyjne. Relacyjna baza danych zapewnia ich zdaniem trwałość danych (pewność ich zapisania) oraz spójność (zapis jest transakcyjny). Rzecz w tym, że bardzo szybko baza danych staje się odbiciem modelu domeny i to 1:1. Do czego to prowadzi?

Po pierwsze do ograniczenia elastyczności modelu domenowego. Jeżeli zachodzi potrzeba większej zmiany w modelu domenowym, np. przeorganizowania encji z powodów biznesowych, to jesteśmy w dupie. Nagle okazuje się, że trzeba przygotować różne dzikie migracje w strukturze tabeli. To pociąga za sobą konieczność przepisania czy to SQLi, czy to mapowiań ORMowych, a na koniec i tak się okazuje, że jest jeszcze cała masa procedur, triggerów i jobów bazodanowych, które nagle tracą sens. A my tylko chcieliśmy wynieść jeden z VO jakiegoś zagłębienia do głównej encji.

Po drugie wszelkie problemy z wydajnością, które wynikają z niedostosowania modelu relacyjnego do pracy w świecie obiektowym, zaczyna się rozwiązywać poprzez pisanie procedur po stronie bazy danych. W efekcie część logiki jest realizowana w bazie danych, część po stronie aplikacji, a część na poziomie procesowym. Oczywiście utrzymanie takiego potwora jest kosztowne i trudne, ale za hajs właściciela/inwestora baluj.

Po trzecie pojawiają się problemy ze składowaniem nietypowych, nierelacyjnych, struktur danych. JSON czy XML zapisany w bazie danych? Why not! Struktury typu słowniki z referencjami i hierarchią jako osobna instancja bazy danych? Dawaj Janusz, będzie dobrze! Co ciekawe na końcu jak całość działa w żółwim tempie, to opierdala się programistów.

Znacznie ciekawiej robi się, gdy zaczynamy wchodzić w środowiska rozproszone. Jak zapewnić transakcyjność w momencie, gdy musimy podzielić nasz system na kilka aplikacji, albo musimy całość rozrzucić w klastrze? Jeszcze zabawniejsze są jednak miny naszych mistrzów projektowania z kwadratów i beczek, gdy mówimy im, że jednak te mikroserwisy, to nie ruszą z jednym oraclem i trzeba zapewnić kilkanaście instancji. Wtedy okazuje się, że hajs i architektura mają pewne powiązania.

A można inaczej…

DataLayer

Naszą przygodę z dodawaniem bazy danych do systemu rozpoczniemy od dodania małej zależności do naszego pom-a w customer-storage/implementation:

Listing 1. Airomem na ratunek

        
        
            pl.setblack
            airomem-core
            1.1.1
        

Na początek wystarczy, że dane będą przechowywane w pamięci. Serio, serio. RAM jest tani, chyba że masz serwery IBMa, to wtedy jest drogi no ale… Następnie należy, to wszystko jakoś pokleić w kodzie.

Generowanie DAO

Plugin JLNS pozwala na wygenerowanie klas reprezentujących DAO, domyślna zawartość interfejsu jest pusta, a implementacja jest oznaczona adnotacją @Repository(value = „COŚTAMDAO”). Po dorzuceniu kilku rzeczy interfejs CustomerDAO wygląda w nastepujący sposób:

Listing 2. Interfejs CustomerDAO

public interface CustomerDAO {

	Option<Customer> getById(UUID customerId);

	Set<Customer> all();

	UUID add(Customer newCustomer);
}

Zwróćcie uwagę na klasę Customer, która będzie reprezentować encję w rozumieniu DDD. Tu będą składowane wszystkie informacje o użytkowniku, które przechowujemy na poziomie jego składowania. W Warstwie usług biznesowych też pojawi się taka klasa, ale będzie miała inne znaczenie.

Następnie musimy dodać prostą implementację, która jest też ładnym przykładem do pewnego wpisu.

Listing 3. Klasa CustomerDAOInMemory

class CustomerDAOInMemory implements CustomerDAO, Serializable {

	private Map storage = new ConcurrentHashMap<>();

	@Override
	public Option getById(UUID customerId) {
		return Option.of(storage.get(customerId));
	}

	@Override
	public Set all() {
		return storage.values()
				.stream()
				.collect(HashSet.collector());
	}

	@Override
	public UUID add(Customer newCustomer) {
		storage.put(newCustomer.getCustomerId(), newCustomer);
		return newCustomer.getCustomerId();
	}
}

Na koniec całość owiniemy w springowy bean, który będzie nam ogarniał logikę związaną z biblioteką airomem:

Listing 4. Klasa CustomerDAOAiromem

@Repository(value = "customerDAO")
public class CustomerDAOAiromem implements CustomerDAO {

	private Persistent controller;

	@Autowired
	public CustomerDAOAiromem(
			@Qualifier("storagePath") Path path,
			@Qualifier("useRoyalFoodTester") boolean useRoyalFoodTester) {
		Path resolve = Paths.get(path.toAbsolutePath().toString(), "customer");
		this.controller = Persistent.loadOptional(resolve,
				CustomerDAOInMemory::new, useRoyalFoodTester);
	}

	@Override
	public Option getById(UUID customerId) {
		return controller.query(c -> c.getById(customerId));
	}

	@Override
	public Set all() {
		return controller.query(CustomerDAOInMemory::all);
	}

	@Override
	public UUID add(Customer newCustomer) {
		return controller.executeAndQuery(c -> c.add(newCustomer));
	}

	@PreDestroy
	void close() {
		controller.close();
	}
}

Jak to uruchomimy, to okaże się, że chyba zgubiliśmy gdzieś naszą bazę danych…

Jak JLNS liczy classpath

JLNS w trakcie uruchamiania usługi podaje classpath. Należy do niego m.in. katalog ./application/customer-storage/, ale korzeniem jest katalog ./start. Trochę to nieintuicyjne, ale jak już o tym się pamięta, to można sobie policzyć classpath. I tak oto możemy zapisywać użytkowników w bazie danych. Jeżeli chcemy zmienić bazę na przykład oracla, to wystarczy podmienić implementację CustomerDAO. W przypadku ORMów trzeba by dodać jeszcze mapowania, ale po pierwsze, jeżeli chcemy to zrobić bez zmian w klasie Customer, to możemy wykorzystać XMLa, albo stworzyć klasę CustomerEntity, która będzie naszym opisem struktury bazodanowej.

Na dziś starczy.

A dziś będzie wideo:

• JLupin Next Server – wprowadzenie i instalacja
• JLupin Next Server – pierwsze kroki, pierwsze usługi

Na początek link do repozytorium GH gdzie leży sobie kod.

Dziś zajmiemy się komunikacją pomiędzy usługami oraz podstawami testowania z wykorzystaniem JLNS.

Konfigurowanie zależności

Jak wspomniałem w poprzednim wpisie, usługi natywne są wewnętrznie podzielone na interfejsy i implementacje. Wykorzystując mavena, możemy uzależniać się od interfejsów, bez konieczności dociągania implementacji. Ma to dwie zalety. Po pierwsze ogranicza ilość kodu jaki, zostanie dodany do naszego finalnego artefaktu. Po drugie pozwala na kulturalną współpracę pomiędzy zespołami. Pośrednikiem będzie tu repozytorium mavena. Miodzio.

Zależności gateway

Gateway udostępnia nam wybrane API. Na tym poziomie musimy zatem mieć zależności do procesów biznesowych. Dlatego w ./AccessLayer/gateway-access/implementation/pom.xml musimy dodać zależności do serwisów z warstwy biznesowej:

Listing 1. pom.xml w gateway

        
        
            pl.koziolekweb.jlns.bankster
            account-business-logic-interfaces
            1.0-SNAPSHOT
        

        
            pl.koziolekweb.jlns.bankster
            customer-business-logic-interfaces
            1.0-SNAPSHOT
        
...

Tu objawia się kolejna mała niedoróbka domyślnej struktury projektu JLupinowego. W takiej strukturze ciężko w jakiś sensowny sposób zarządzać wersjami usług. Z jednej strony można wszystko po prostu zapisać jako zmienną i podstawiać wszędzie gdzie trzeba. Rzecz w tym, że tych zmiennych może być dużo. Drugim sposobem może być wykorzystanie parametru ${parent.version}, ale zadziała to tylko w przypadku natywnych mikroserwisów. Mikroserwisy servletowe jako „rodzica” mają ustawionego SpringBoota w wersji 1.5, co niestety nie jest parametryzowane z poziomu kreatora i jest kolejną małą niedoróbką. Przy czym problemu wersjonowania usług w sensowny sposób to jeszcze nikt dobrze nie wymyślił, a JLNS tak naprawdę deleguje problem do użytkownika.

A co z dostępem do usług ogarniających dane? Moim zdaniem, to ważne, nie należy ich linkować bezpośrednio do gatewaya. Wynika to ze sposobu, w jaki publikowane są usługi i może spowodować, że ujawnimy za dużo. Nawet jeżeli na poziomie warstwy biznesowej serwis pośredniczący będzie tępą rurą bez logiki, to nadal daje nam to separację modelu danych na niskim poziomie od eksponowanego modelu.

Zależności w serwisach biznesowych

Tu zasada jest ta sama. Z tą małą różnicą, że zależność dodajemy tylko do pom-a w module z implementacją np.

Listing 2. zależność w ./BusinessLogicLayer/customer-business-logic/implementation/pom.xml

	
	
		pl.koziolekweb.jlns.bankster
		customer-storage-data-interfaces
		1.0-SNAPSHOT
	
...

I tak oto mamy już ogarniętą konfigurację na poziomie zależności. Czas na zabawę w kodzie.

Jak korzystać z usług?

Proces konfiguracji zależności już za nami. Teraz mamy dostęp do interfejsów, a JLNS zrobi z nich interfejsy zdalne. Tyle tylko, że trzeba mu trochę w tym pomóc. Zrobimy to na przykładzie usługi customer-storage. Wystawimy z niej prosty interfejs StorageCustomerBasicInformationService, który wygląda następująco:

Listing 3. Interfejs StorageCustomerBasicInformationService

public interface StorageCustomerBasicInformationService {

	Set<BasicCustomerInformation> all();

	Option<BasicCustomerInformation> byId(UUID customerId);
}

Klasa CustomerBasicInformationService znajduje się w module common-pojo, a to dlatego, że jest to minimalny zbiór informacji o kliencie. Coś w rodzaju VO klienta. Będziemy z tej klasy korzystać w wielu miejscach i można przyjąć, że na poziomie systemu to element naszego języka domenowego (Podstawowe Dane Klienta, czyli PaDaKa). Sam interfejs znajduje się w module interfaces.

Kolejnym krokiem jest implementacja tego interfejsu w module implementation. Oczywiście nie mam zamiaru tego pisać z palca. W InteliJ rozwijamy moduł implementation i odnajdujemy pakiet COŚTAM.service.impl, naciskami alt+insert i:

Następnie podajemy nazwę serwisu bez przyrostka Service, ten zostanie dodany automatycznie.

W efekcie zostaną wygenerowane dwa pliki (interfejs i klasa):

//offtop
Po drodze zrobiłem refaktoryzację nazw, by było łatwiej, więc nie do końca trzyma się to to z obrazkami kupy.
//koniec offtopa

Upublicznienie usługi

Teraz należy jeszcze usługę upublicznić. Generator nie tylko stworzył pliki, ale też zmodyfikował klasę CustomerStorageSpringConfiguration:

Listing 4. Klasa CustomerStorageSpringConfiguration

@Configuration
@ComponentScan("pl.koziolekweb.jlns.bankster")
public class CustomerStorageSpringConfiguration {
	@Bean
	public JLupinDelegator getJLupinDelegator() {
		return JLupinClientUtil.generateInnerMicroserviceLoadBalancerDelegator(PortType.JLRMC);
	}

	@Bean(name = "jLupinRegularExpressionToRemotelyEnabled")
	public List getRemotelyBeanList() {
		List<String> list = new ArrayList<>();
		list.add("storageCustomerBasicInformationService");
		return list;
	}
}

JLupin na podstawie listy nazwanej jLupinRegularExpressionToRemotelyEnabled odszuka i opublikuje wybrane serwisy. Tu bardzo ważnym elementem jest nadanie naszym springowym beanom nazw. Co prawda istnieje konwencja nazewnicza, dzięki której możemy wykorzystać domyślne nazwy, ale może być ona źródłem różnych pomyłek. Zatem nasza implementacja wygląda w następująco:

Listing 5. Interfejs StorageCustomerBasicInformationServiceImpl

@Service(value = "storageCustomerBasicInformationService")
public class StorageCustomerBasicInformationServiceImpl implements StorageCustomerBasicInformationService {
	@Override
	public Set<BasicCustomerInformation> all() {
		return HashSet.empty();
	}

	@Override
	public Option<BasicCustomerInformation> byId(UUID customerId) {
		return Option.none();
	}
}

Używam tu Vavr, bo chcę mieć serializowane kontenery. Dlaczego? O tym za chwilę. Przejdźmy do konfiguracji po stronie klienta.

Konfiguracja kliencka

Klientem naszej usługi jest serwis customer-business-logic. Dlatego też udamy się teraz do klasy konfiguracyjnej CustomerSpringConfiguration:

Listing 6. Klasa CustomerSpringConfiguration

@Configuration
@ComponentScan("pl.koziolekweb.jlns.bankster")
public class CustomerSpringConfiguration {
	@Bean
	public JLupinDelegator getJLupinDelegator() {
		return JLupinClientUtil.generateInnerMicroserviceLoadBalancerDelegator(PortType.JLRMC);
	}

	@Bean(name = StorageCustomerBasicInformationService.name)
	public CustomerBasicInformationService getStorageCustomerBasicInformationService() {
	     return JLupinClientUtil.generateRemote(getJLupinDelegator(),
			     "customer-storage",
			     StorageCustomerBasicInformationService.name,
			     StorageCustomerBasicInformationService.class);
	}

	@Bean(name = "jLupinRegularExpressionToRemotelyEnabled")
	public List getRemotelyBeanList() {
		List<String> list = new ArrayList<>();
		return list;
	}
}

Uwaga! Po drodze wyrzuciłem jeszcze nazwę serwisu, którą używamy w nazwie beana na poziom interfejsu. Taka mała rzecz, a cieszy i daje trochę większą kontrolę nad tym, co się dzieje.

Metoda getStorageCustomerBasicInformationService produkuje nam proxy, które opakowuje JLupinowy mechanizm wywołań zdalnych. W naszym kodzie możemy później użyć takiego wywołania tak, jak byśmy wywoływali zwykłą, lokalną, metodę. Bardziej doświadczeni czytelnicy rozpoznają tu zapewne mechanizm RMI obecny w EJB. Podstawowa różnica pomiędzy tymi rozwiązaniami leży w sposobie ich implementacji. To, czy dany interfejs jest dostępny zdalnie, czy też nie jest definiowane na poziomie konfiguracji, a nie interfejsu. Nie ma ty adnotacji Local czy Remote, bo nie są do niczego potrzebne. Co prawda można by dodać adnotację, która by wyszukiwała za nas implementacje, ale to szczegół. Zresztą i tak musimy przepchnąć nasze obiekty dalej do gateway-a. Powtórzymy zatem proces tworzenia serwisu na poziomie warstwy usług biznesowych i skonfigurujmy usługę tak, by można było jej używać z zewnątrz. Nasza implementacja będzie wyglądać następująco:

Listing 7. Klasa CustomerSpringConfiguration

@JLupinService
@Service(value = CustomerBasicInformationService.name)
public class CustomerBasicInformationServiceImpl implements CustomerBasicInformationService {

	private final StorageCustomerBasicInformationService delegate;

	@Autowired
	public CustomerBasicInformationServiceImpl(StorageCustomerBasicInformationService delegate) {
		this.delegate = delegate;
	}

	@Override
	public Set<BasicCustomerInformation> all() {
		return delegate.all();
	}

	@Override
	public Option<BasicCustomerInformation> byId(UUID customerId) {
		return delegate.byId(customerId);
	}
}

Testy integracyjne

Na tym etapie wystarczyło by zrobić mvn clean install i po problemie. Zanim jednak tak zrobimy musimy jeszcze trochę rzeczy związanych z testowaniem. W zasadzie testowanie integracyjne w JLNS nie różni się zasadniczo od zwykłych testów integracyjnych. W module integration-test dodajmy sobie prosty test naszego CustomerBasicInformationService

Listing 8. Klasa CustomerBasicInformationServiceITest

public class CustomerBasicInformationServiceITest extends BaseTest {

	 @Test
	 public void exampleTest() {
	    CustomerBasicInformationService service = JLupinClientUtil.generateRemote(getJLupinDelegator(),
			    "customer",
			    CustomerBasicInformationService.name,
			    CustomerBasicInformationService.class);
		 Assertions.assertThat(service.all()).isEmpty();
	 }
}

Klasa BaseTest przygotowuje nam prostego klienta, który będzie komunikować się z serwerem na localhost.

Uruchomienie

Pozostało nam to wszystko uruchomić. Wystarczy zatem uruchomić serwer i następnie odpalić mvn clean install. Poniżej nagrałem ten proces (koniecznie full screen):

Górna połowa to oczywiście maven. Dolna to podgląd konsoli JLNS. Ładnie widać jak wstają kolejne serwisy.

Podsumowanie

Podstawowa komunikacja pomiędzy serwisami w ramach JLNS jest bardzo prosta, a dzięki kilku „sztuczkom ze Springiem” można to ładnie ogarnąć. Fajne, prawda?

// edit: w Listingach 6 i 8 zabrakło jednej linijki. Nazwy usługi do której się odwołujemy.

W poprzednim wpisie było trochę dupereli o mikroserwisach. Dlaczego są nie do końca OK oraz jak JLupin może pomóc nam ogarnąć tę kuwetę. Dziś będziemy bawić się już w programowanie i na przykładach zademonstruję co i jak.

Co piszemy?

Jak już 11 lat bloga prowadzę, to zawsze przewijał się na nim temat bankowości. Banki duże, banki małe, systemy rozliczeniowe, windykacyjne, transakcyjne, raportowanie i cała masa innych niegodziwych elementów tego szatańskiego tworu zwanego systemem bankowym. Dlatego też bez zaskoczenia. Napiszemy bank. Dokładnie napiszemy sobie fragment związany z kontami, klientami i jakieś proste raportowanie. Docelowo będziemy mieli tu kilka aspektów, które ładnie będzie można przenieść na poszczególne usługi:

• Klienci i konta – informacje o klientach i ich kontach, czyli takie typowe CRUD-owe usługi.
• Operacje finansowe – tu będzie się działo mięsko związane z przelewaniem kasy.
• Raportowanie – zazwyczaj w takim miejscu jest jakiś system raportowo-analityczny, my zrobimy sobie wydmuszkę.
• Parametryzacja – pewne elementy banku muszą być pobierane z parametrów biznesowych.
• API Gateway – końcówka dla klientów.

By jeszcze sobie utrudnić życie, a jednocześnie móc zademonstrować kilka elementów JLNS, wprowadzimy funkcjonalność „partnerów”, czyli coś, co na co dzień znamy jako kredyty sprzedawane w sklepach z AGD, albo karty kredytowe marketów.

// offtop

Od wczoraj żyjemy z RODO, a to oznacza, że takie produkty jak np. karta kredytowa „Stonka i Ty” muszą mieć znacznie ciekawszą konstrukcję. Jak będziecie brać kredyt w markecie, to wczytajcie się w regulaminy, bo może okazać się, że kredytodawcą jest jakiś niezbyt ogarnięty bank.

// koniec offtopa

Oczywiście będzie dużo uproszczeń (albo i nie), ale na początek zajmiemy się czymś zupełnie trywialnym Przygotujemy projekt w IntelliJ. Jest to o tyle proste, że JLNS udostępnia wtyczkę do IDE. Obrazkowo będzie.

Projekt Bankster

Na początku oczywiście menu „Create new Project” i następnie wybieramy projekt JLupinowy

Kolejnym krokiem jest określenie wersji grupy mavenowej oraz miejsca, w którym zapisaliśmy zipa zawierającego serwer. Osobiście uważam, że osadzanie serwera w ramach projektu jest po prostu wygodne. Czasami trzeba coś pogrzebać w konfiguracji czy rzucić okiem na logi.

Następnie stworzymy sobie projekt, który będzie ogarniał API Gateway:

Do tego dodajmy projekty dla klienta i rachunków oraz ich „tło” do składowania danych:

Na koniec nadajemy całości nazwę bankster i gotowe:

Na obecnym etapie otworzy się okno IDE, w którym mamy podgląd do naszej architektury:

Podgląd co prawda nie jest najlepszy, bo nie pozwala nam na tworzenie zależności za pomocą drag’n’drop, ale lepsze to niż nic. Szczególnie że przy większych projektach i tak szybciej będzie dodać zależność w pom.xml niż kombinować z myszką.

Struktura projektu

Przyjrzyjmy się teraz strukturze projektu. Pierwszą rzeczą, która rzuca się w oczy, jest organizacja modułów. Poszczególne projekty są modułami głównego projektu. I to jest nie do końca OK. Taki układ wymusza na nas pracę z projektem jak z monolitem. W dodatku trudno będzie zarządzać takim projektem, tak by poszczególne usługi miały swoje repozytoria. Moim zdaniem jest to bardzo duży błąd ze strony twórców. Z drugiej strony pozwala, to na zarządzanie całością z jednego miejsca. Trochę innym podejściem jest stworzenie projektu typu bom, w którym upakujemy konfigurację zależności. Przyjmijmy jednak, że ta domyślna konfiguracja ma jakiś głębszy sens. Przyjrzyjmy się, jak wyglądają poszczególne projekty.

Zacznijmy od gatewaya. Projekt ten umieszczony jest w katalogu ./AccessLayer/gateway-access/. Znajdziemy tam dwa katalogi. Pierwszy to additional-files, w który znajdują się dwa pliki:

• log4j2.xml – zawiera konfigurację log4j2, która zostanie wykorzystana przez techniczne elementy usługi. Jest to też domyślny log usługi.
• servlet_configuration.yml – tu znajdziemy konfigurację usługi, która obejmuje kanały komunikacyjne, pamięć, bufory, ale też na przykład zasady rotowania logów.

Pozostałe podprojekty mają taką samą strukturę. Przy czym projekty z warstwą biznesową znajdują się w katalogu ./BusinessLogicLaywer/{account,customer}-businesslogic/, a projekty związane z dostępem do danych w katalogu ./BusinessLogicLaywer/{account,customer}-storage-data/. Sama struktura poszczególnych projektów jest następująca:

• ./additional-files/ – to samo co wyżej, czyli konfiguracja, ale zamiast servlet_configuration.yml, mamy configuration.yml.
• ./interfaces/ – w tym projekcie definiujemy interfejsy naszej usługi. Co ważne inne usługi korzystające z naszego serwisu będą zależne od tego właśnie projektu.
• ./implementation/ – implementacja naszych usług. Tym się nie musimy z nikim dzielić.

Poza wyżej wymienionymi elementami mamy jeszcze:

• common-pojo – w tym projekcie leżą sobie klasy, które reprezentują pewne podstawowe struktury danych w naszym systemie. W praktyce to kubeł na różne VO.
• common-utils – skrzynka na narzędzia. Tu umieść klasę StringUtils. Na pewno będziesz jej potrzebować.
• integration-test – w tym miejscu leżą testy integracyjne, które można odpalić w procesie CI/CD.

Rodzaje mikroserwisówserwisów

Taka organizacja poszczególnych projektów jest wynikiem wyróżnienia dwóch rodzajów mikroserwisów.

Mikroserwisy servletowe

Pod tą nazwą kryją się mikoserwisy, które są aplikacjami webowymi. Co do zasady jest to spring boot. Mikroserwisy te wystawiają API na potrzeby naszych klientów. Na tym poziomie mamy dostęp do naszej aplikacji za pośrednictwem HTTP(S) i możemy pisać aplikacje zgodne ze specyfikacją servletową. Z drugiej strony usługi te są pozbawione wbudowanych kolejek, które pozwalają na tworzenie reaktywnych rozwiązań. Nie jest to nic dziwnego, bo tu nie potrzebujemy tego typu magii.

Mikroserwisy natywne

Czyli aplikacje (jary), które zawierają logikę biznesową, zarządzają danymi, komunikują się z innymi, zewnętrznymi usługami. Tych usług nie wystawiamy na zewnątrz bezpośrednio. Jednocześnie stanowią one największą część naszej aplikacji.

Podsumowanie

Praca z JLNS w zakresie tworzenia projektów jest bardzo prosta. Z drugiej strony niektóre pomysły twórców uważam za swoistą pomyłkę np. super-projekt mavenowy. Warto też zwrócić uwagę na jeszcze jeden aspekt. JLNS bardzo intensywnie wykorzystuje Spring Framework, ale jeżeli chcemy pisać bez wsparcia ze strony Springa, to nadal możemy to robić. W kolejnej części zaczniemy wiązać usługi między sobą i zaimplementujemy jakiś prosty przypadek użycia.