Consileon Dev Blog

CQRS/DDD/ES w pigułce

2012-02-28T00:00:00-08:00

O czym traktuje wpis:

CQRS - Command Query Responsibility Segregation
DDD - Domain Driven Design
ES - Event Sourcing

Koncepcja CQRS

Podział systemu na dwa obszary: 1. przetwarzanie transakcji 2. obsługa zapytań (widoki)

Architektura systemu, która wyłania się w wyniku zastosowania takiej separacji, jest zasadniczo różna względem typowych architektur bazujących na jednym modelu danych i jednej warstwie serwisowej obsługujących zarówno zapisy jak i odczyty. Dzięki separacji można niezależnie optymalizować obydwa obszary systemu.

Event Sourcing i DDD to rozwiązania, które umożliwiają implementację koncepcji CQRS.

DDD

Metodyka DDD dostarcza wytyczne w jaki sposób modelować logikę biznesową. Podstawowe koncepje DDD: - Ubiquitous Language - modele powstają (wyłaniają się) w wyniku dogłębnej analizy domeny i są opisywane językiem zrozumiałym dla developerów jak i ekspertów domenowych (których udział w procesie analizy domeny jest niezwykle pożądany) - Bounded Contexts - zwykle w ramach jednego systemu występuje wiele domen, które należy opisywać odrębnymi modelami - Aggregates - agregaty są głównymi elementami modelu, grupują powiązane ze sobą obiekty, których modyfikacja możliwa jest tylko za pośrednictwem obiektu głównego (Aggregate Root) (AR), co zapewnia kontrolę nad spójnościa agregatu

Event Sourcing

Event Sourcing to koncepcja, w której stan obiektu reprezentowany jest jako suma zdarzeń (Events) jakie zostały wygenerowane przez ten obiekt. Każda modyfikacja stanu obektu skutkuje wygenerowaniem przez obiekt zdarzenia reprezentującego tę modyfikację. Dla przykładu, obiekt Invoice może być reprezentowany jako suma zdarzeń InvoiceCreated, InvoiceItemAdded, InvoiceSent. To AR wie co zostało zmienione i jest to jawnie reprezentowane przez Event.

Optymalizacja przetwarzania transakcji

System akceptuje wywołania operacji biznesowych w formie komend. Przetwarzanie komendy polega na wywołaniu pojedynczej metody w Aggregate Root. Metoda nie zwraca żadnego wyniku, a brak wyjątku oznacza pomyśle zakończenie operacji. Komenda nie musi być przetworzona natychmiast (może zostać zakolejkowana).

Aggregate Root wyznacza granice spójności

Aggregate Root gwarantuje integralność (spójność) danych które obejmuje. Możliwa jest dowolna optymalizacja wewnętrznej struktury agregatu dla celów przetwarzania transakcji bez konieczności uwzględniania warstwy prezentacji

Aggregate Root wyznacza granice transakcji

Transakcja nie może obejmować kilka AR, a więc AR nie może posiadać referencji do innego AR (może posiadać jedynie jego Id) Dzięki temu możliwe jest partycjonowanie AR.

Append-only storage

Zmiany stanu Aggregate Root sygnalizowane są zdarzeniami (Event), które na koniec transakcji serializowane są do bazy (Event Store). Rozwiązanie to zapewnia ogromną wydajność przetwarzania transakcji dzięki temu, że nie jest konieczne tworzenie locków na bazie danych oraz wykonywanie skomplikowanych zapytań sql. Event Store może wykorzystywać dowolny mechanizm utrwalania (baza sql, nosql, pliki) i jest łatwy w utrzymaniu (backup'y, replikacja). Oczywistą konsekwencją jest brak możliwości wykonywania zapytań sql, stąd Aggregate Root może być ładowany tylko na podstawie Id.

Asynchroniczne przetwarzanie zdarzeń

Zdarzenia są asynchronicznie propagowane do zarejestrowanych słuchaczy (Event Handler), a zatem przetwarzanie ich nie wydłuża czasu trwania transakcji. W ten sposób aktualizowana jest druga strona systemu (widoki). Konsekwencją jest opóźnienie pomiędzy zatwierdzeniem transakcji a aktualizacją widoku. To samo opóźnienie może dotyczyć aktualizacji stanu innych ARs, które są wywoływane przez Event Handler'a (wysłanie komendy) w wyniku zaistnienia określonego zdarzenia. Spójność pomiędzy ARs (rozumiana jako spójność transakcyjna) nie jest zatem zachowana. Gwarantowana jest natomiast ostateczna spójność (Eventual Consistency) - każdy AR w końcu zostanie zaktualizowany.

Możliwość zatwierdzania równoległych zmian

Można odrzucać równoległe zmiany w aggregacie tylko dla określonych zdarzeń. Np. zmiana adresu użytkownika nie konfiktuje ze zmianą jego statusu. Mechanizm ten szczególnie jest przydatny jeśli klienci pracują w trybie off-line. W momencie synchronizacji z serwerem, prawdopodobieństwo wystąpienia zmian równoległych jest dużo większe.

Testowanie

Testowanie logiki biznesowej jest czytelne i efektywne. Szkielet metody testującej wygląda następująco:

// given
// create AR by replying list of events

// when
// dispatch a Command

// then
// expect given list of events or exception

W testach weryfikujemy zatem tylko to czy wygenerowane zdarzenia odpowiadają tym oczekiwanym.

Optymalizacja obsługi zapytań

Widoki mogą być w dowolny sposób budowane (baza sql, baza dokumentowa, nosql). W przypadku użycia bazy sql, widoki mogą być zdenormalizowane (dla zapewnienia maksymalnej wydajności zapytań). W trakcie rozwoju systemu możliwe jest łatwe tworzenie dowolnych nowych widoków / raportów. Wypełnienie nowych widoków danymi historycznymi jest możliwe dzięki odtworzeniu zdarzeń historycznych z Event Store.

Task based UI

Interfejs użytkownika odzwierciedla komendy akceptowalne przez system.

Kiedy stosować CQRS

Aby zdefiniować komendy i zdarzenia, wymagane jest dobre zrozumienie domeny i jej dekompozycja. Z uwagi na powyższe, CQRS nie koniecznie nadaje się do zastosowania dla całego systemu. Domeny dla których zastosowanie CQRS niesie największe korzyści to te, które z jednej strony stanowią o wartości biznesowej systemu, z drugiej strony wymagają optymalizacji pod kątem możliwości udostępniania (i modyfikacji) tych samych bądź powiązanych danych wielu użytkownikom systemu jednocześnie (collaborative domains).

Event Driven Architecture

Stosowanie CQRS z użyciem ES zachęca do budowania systemów sterowanych zdarzeniami. Poszczególne moduły systemu (obsługujące różne dziedziny biznesowe (Bounded Contexts)) mogą komunikować się ze sobą za pomocą zdarzeń (push integration). Każdy moduł korzysta tylko z danych lokalnych, które aktualizuje w oparciu o zdarzenia odbierane z innych modułów. Dzięki takiej architekturze, możliwe jest czasowe wyłączenie poszczególnych modułów bez konsekwencji dla całego systemu.

http://pkaczor.blogspot.com/2012/02/cqrsdddes-w-piguce.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

Saga vs Batch Processing (Spring Batch introduction)

2012-02-27T00:00:00-08:00

When dealing with business process often some state transitions are not immediately executed as result of human interaction but rather being scheduled for future execution. One example could be expiration of Payment Period (see previous blog for domain description).

Modelling such process execution flow explicitly in the code is the right thing to do if we want to keep process logic maintainable and self describing. That's why we should apply bpm tools or Saga pattern (if we prefer simple and light-weight solution) to do the job.

Scheduling activity within Saga

The following code shows how to schedule activity within Saga (Axon implementation):

class PaymentPeriodSaga extends AbstractSaga {

    @StartSaga
    @SagaEventHandler(associationProperty = "paymentPeriodId")
    public void paymentPeriodCreated(PaymentPeriodCreatedEvent event) {
        associateWith("accountId", event.getAccountId());
        getEventScheduler().schedule(
          // trigger datetime
          event.getValidityInterval().getEnd(), 
          // the event to publish
          new PaymentPeriodExpiredEvent(event.getContext(), event.getAggregateId())
            );
    }

    @SagaEventHandler(associationProperty = "paymentPeriodId")
    public void paymentPeriodExpired(PaymentPeriodExpiredEvent event) {
        RenewAccountCommand command = new RenewAccountCommand.Builder(event.getContext())
            .accountId(getAssociatedId("accountId"))
            .build();
        
        getCommandBus().dispatch(command);
    }
}

When (current) Payment Period is created, RenewPaymentPeriodCommand is scheduled for execution on time when the period expires (after validation interval passes). This approach is clean, easy to implement and test but...requires (mind) shifting from procedural way of modelling business logic (see transaction script) towards event driven architecture (EDA). For those who are not yet ready to enter EDA and bpm, there is an old-time heavy-weight, bullet-proof way of executing scheduled tasks on certain time: batch processing.

Batch processing

Batch processing is suitable for optimizing execution of high-volume, repetitive tasks in such way that system is under heavy load only within relatively short time window (batch window). (See http://en.wikipedia.org/wiki/Batch_processing)

Our goal will be to execute Payment Period renewal in batch mode. Instead of scheduling each Payment Period renewal explicitly in the business process (saga), batch job (RenewPaymentPeriodsJob) scheduled to run repeatedly (every hour or day depending on requirements) will invoke RenewPaymentPeriodCommand for all expired Payment Periods that it will find in database. We will only change processing mode but will not touch business logic that will be still encapsulated inside of aggregate roots and event listeners. We will use the same commands dispatching mechanism that is used for online transactions processing avoiding creation of specialized services or using sql statements to implement batch jobs (as one could expect from batch jobs:) ).

Running jobs in batch mode gives more control over system load. It can be controlled how often and when batch jobs should be run. In Saga, execution model is different, operations are executed automatically and there is no control mechanism at runtime. Which way is better..? As always, depends. But it is good to have both alternatives ready to apply when time comes...

Lets see how to use Spring Batch, modern batch framework for JVM, to apply batch processing using commands and queries as building blocks.

Spring Batch processing model

The diagram above highlights the key concepts that make up the domain language of batch. A Job has one step or combines multiple steps that belong logically together in a flow. Each step has exactly one ItemReader, ItemProcessor, and ItemWriter. A Job needs to be launched (JobLauncher), and meta data about the currently running process needs to be stored (JobRepository).

Spring Batch uses a "Chunk Oriented" processing style within its most common implementation. Chunk oriented processing refers to reading the data one at a time, and creating 'chunks' that will be written out, within a transaction boundary. Committing a transaction, at each commit interval, commits a 'chunk'.

The data item could be line in a file or record in a database table but Spring Batch integrates modern to-object mapping frameworks so we don't have to dirty our hands by manipulating low-level data.

Spring Batch application

Our goal is to use Aggregate Roots as processing items. To build batch step we need to implement an ItemReader that will fetch ARs (entities) from database by executing provided query and an ItemProcessor that will build a command based on AR data and dispatch command to the system. Since batch processing is performed transactionally (chunks are automatically committed by Spring Batch with use of provided transaction manager) commands need to to be dispatched synchronously. This logic of batch step may be shared across different jobs as long as the concept of ItemReader responsible of fetching ARs using provided query and ItemProcessor responsible for dispatching command is preserved. What will distinguish different steps from each other is query specification and command to be executed.

So lets define interface that will describe these responsibilities of batch step:

public interface BatchStepSpecification <C extends Command, R> {

    C getCommand(R queryResultItem);
    
    QuerySpecification<R> getQuerySpecification();
}

BatchStepSpecification object should be able to provide query specification (executable by ItemReader, more on query specifications in a moment) and build Command (for each AR to be processed) executable by ItemProcessor.

Now we need to implement ItemReader and ItemWriter that will use step specification to do their job.

ItemReader

To avoid keeping all entities to be processed in memory (this could be a large set) Spring Batch offers two solutions: Cursor and Paging database ItemReaders. Let's go with the letter one. For loading entities from database in a paging fashion Spring Batch provides several implementations of AbstractPagingItemReader one of them being JpaPagingItemReader for fetching JPA entities. JPAPagingItemReader allows you to define query by providing JPQL statement. But we want our queries be more maintainable and composable. Therefore I recommend to represent JPA queries as Specifications. This is possible with use of Spring Data JPA module. Specification can be translated into JPA Query in the following way:

public Query createQuery(QuerySpecification<? extends Entity> spec) {
    CriteriaBuilder builder = getEntityManager().getCriteriaBuilder();
    CriteriaQuery criteriaQuery = builder.createQuery(spec.getResultClass());
    Root root = criteriaQuery.from(spec.getResultClass());
    criteriaQuery
                .where(
                    spec.toPredicate(root, criteriaQuery, builder)
                )
                .select(root);
    return getEntityManager().createQuery(criteriaQuery);
}

More about specifications you can read here: Advanced Spring Data JPA – Specifications And QueryDSL.

Implementing SpecificationPagingReader is straightforward. Main thing to do is to implement doReadPage() method:

class SpecificationPagingReader extends AbstractPagingItemReader<Entity> {
//[...]
    private Specification querySpecification;

    @Override
    @Transactional(readOnly=true)
    public void doReadPage() {
        //[...]
        Query query = createQuery(querySpecification).setFirstResult(getPage() * getPageSize()).setMaxResults(getPageSize());
        results.addAll(query.getResultList());
    }
}

Finally, we can define our ItemReader in Spring context:

<bean id="reader" scope="step" class="a.b.c.SpecificationPagingReader"
    p:entityManagerFactory-ref="entityManagerFactory"
    p:querySpecification="#{stepSpecification.querySpecification}"
    p:pageSize="2000"
/>

The instance of SpecificationPagingReader will be created automatically by Spring whenever batch step is executed. This is the magic of step scope provided by Spring Batch. It allows late (dynamic) binding of properties. In our case stepSpecification is unknown until particular step is executed (more details ahead).

ItemProcessor

ItemProcessor interface defines just one method. The implementation in our case is simple:

class EntityProcessor implements ItemProcessor<Entity, Entity> {
    private CommandBus commandBus;
    private BatchStepSpecification<Command, Entity> stepSpecification;
    
    @Override
    public Entity process(Entity item) throws Exception {
        Command command = stepSpecification.getCommand(item);
        commandBus.dispatch(command);
        return item;
    }
}

And Spring bean definition:

<bean id="processor" scope="step" class="a.b.c.EntityProcessor"
    p:commandBus-ref="commandBus"
    p:stepSpecification="#{stepSpecification}"
/>

ItemWriter

ItemWriter must be provided as well but it can be empty implementation assuming all changes to ARs are flushed to database as a result of command processing within the service.

Finally we are able to build batch step that will be reused by concrete batch jobs.

Batch Step

<step id="abstractBatchStep" abstract="true">
    <tasklet>
    <chunk reader="reader" processor="processor" writer="writer" 
        commit-interval="10" skip-limit="5">
        <skippable-exception-classes>
            <include class="java.lang.Exception"/>
        </skippable-exception-classes>
    </chunk>
    </tasklet>
</step>

Here, we compose three beans (reader, processor, writer) and additionally provide following parameters: - skip-limit - the maximum number of items that will be allowed to be skipped (in case the processing of item ends with exception). Once the skip limit is reached, the next exception found will cause the step to fail. - commit-interval - how many items will be processed in one transaction (chunk size), value > 1 might increase performance, but also could result in rollback of successfully processed ARs (if exception skip limit is reached) - skippable-exception-classes - exceptions that will result in skipping the processed entity instead of step failure

Job registry

Now we can define our jobs. The easiest way is to use AutomaticJobRegistrar class. Registration in this case is performed automatically on application start-up, based on defined path under which spring context files containing jobs definitions are located. By putting each job bean into separate spring context file we are able to provide its stepSpecification bean that will be created when job's step is executed. If all those files were imported into the same context, the stepSpecification definitions would clash and override one another, but with the automatic registrar this is avoided.

Please see example definition of batch job:

<job id="renewPaymentPeriodsBatchJob">
    <step id="renewPaymentPeriodsJob" parent="abstractBatchStep"/>
</job>
<bean id="stepSpecification" class="a.b.c.RenewPaymentPeriodsBatchStepSpecification" />

As shown above, creating new batch job is just a matter of creating new spring context file containing job id (globally unique), step id and step specification bean. Nothing more is required. The solution is powerful and simple but has one limitation. We can not create jobs with several steps, each one configured with different BatchScopeSpecification. For example:

<job id="accountsMaintenanceJob" parent="abstractBatchJob">
    <step id="step1">
        <job ref="endAccountsBatchJob"/>
        <next on="*" to="step2" />
    </step>
    <step id="step2">
        <job ref="renewPaymentPeriodsBatchJob"/>
    </step>
</job>

I found a solution for this problem, in case you are interested, let me know by dropping in a comment.

Job execution

To execute a Job, we need to create JobParameters object and use JobLauncher to run Job with created parameters. Please refer to description of artifacts related to batch job execution. It is important to understand differences between Job, JobInstance and JobExecution.

Things to remember:

JobInstance = the concept of a logical job run (Job + JobParameters)
JobExecution = a single attempt to run JobInstance. JobInstance corresponding to a given execution will not be considered complete unless the execution completes successfully. There can be more than one failed JobExecutions but only one successful execution of given JobInstance.

Batch jobs scheduling

Spring Batch is not a scheduling framework. It is entirely up to the scheduler to determine when a Job should be run. There is no requirement that one JobInstance be kicked off after another, unless there is potential for the two job instances to attempt to access the same data, causing issues with locking at the database level. But attempting to run the same JobInstance while another is already running will result in a JobExecutionAlreadyRunningException being thrown.

Other Spring Batch Goodies

Restartability - the framework periodically persists the ExecutionContext at commit points. This allows the ItemReader to store its state in case a fatal error occurs during the run, or even if the power goes out. JpaPagingItemReader supports restart by storing item count, therefore requires item ordering to be preserved between runs.
Non Sequential Step Execution - conditional flow of steps
Partitioning - JobOperator interface for common monitoring tasks such as stopping, restarting, or summarizing a Job, as is commonly done by batch operators.

http://pkaczor.blogspot.com/2012/02/saga-vs-batch-processing-spring-batch.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

Axon Framework - DDD and EDA meet together

2011-08-02T00:00:00-07:00

CQRS (Command Query Responsibility Segregation) is a new approach towards building scalable and distributed systems that is based on simple pattern know as Command Query Separation (CQS). In short, you should design your system in a way that it either processes a command or serves response to a query. CQRS in its core is quite simple. Just split your service interface into two parts: Query Service and Command Service and you are done. But what is important is that by making this simple separation, you make your system open to many opportunities for architecture that may otherwise not exist. In this article I will not show you what is possible when fully applying CQRS (check this CQRS Starting Page for details). Instead I will present you how some design patterns can effectively be applied to standard ORM-based application when you decide to split your interface into Commands and Queries and use Axon - CQRS framework for Java. But first we must talk about DDD as it plays crucial role in building scalable and maintainable systems and fits very well to CQRS-based architecture.

DDD shortly

Generally DDD is about domain model that, when expressed in Ubiquitous Language, can be shared by developers and domain experts allowing them to communicate effectively. From technical point of view DDD is about modeling your core domain using aggregate roots (AR), entities, value objects and some other artifacts like domain services and repositories. What is important, when applying DDD to medium or large domains (generally complex domains are good candidates for DDD), you should not be expecting one model to arise representing all areas covered by the system. Each area will likely be modeled separately (inside its own Bounded Context. This aspect is very important, especially if your application starts to grow covering more and more business activities. If you stick with one model aka EDM (Enterprise Domain Model) (that typically reassembles model of relations inside your sql database), you will end up with monolithic system not capable of adjusting to business requirements. Therefore building application DDD-way should be seen as completely different approach comparing to standard approach (one model to rule them all approach). You will need additional means to express communication between your different models (Bounded Contexts). Thats where EDA - event based communication comes in.

Let's see how to apply DDD and EDA to standard ORM-based application with use of Axon.

Axon introduction

Axon framework provides building blocks for CQRS applications. Some blocks, i.e. event sourcing, asynchronous processing of commands (no response from Command Handler)) are optional and can be omitted. If you are not ready for (or just don't need) full CQRS, you can still benefit from other goodies such as synchronous command handling, events, sagas and others. Additionally Axon integrates deeply with Spring making configuration a trivial task (just use built in namespaces (xml part) and annotations). Unique feature of Axon is that it allows to integrate existing JPA-based application. To make your entities become Aggregate Roots extend AbstractAggregateRoot class, to load your ARs from database use GenericJpaRepository (or even better HybridJpaRepository if you want to use EventStore). For detailed instructions see User's Guide. Lets start working with code.

Get rid of Trasaction Script

When applying DDD, we tend to build rich entities that encapsulate behavior. In contrast to standard approach with anemic domain model and procedural code inside Application Services (see: Transaction Script), most of business logic should be handled inside Aggregate Roots. When a command comes in, it is dispatched to Command Handler whose only job should be to get AR from Repository and invoke single method on it.

Lets imagine a system that manages user accounts (Account AR). One of Account's properties is state. To activate an account, AccountActivateCommand must be sent by the client. In order to handle this command, we must register and implement specialized Command Handler:

class AccountCommandHandler {
    @CommandHandler
    public Account activate(AccountActivateCommand command) {
        Account account = accountRepository.findById(command.getAggregateId());
        account.activate();
        return account;
    }
}

That's it. Nothing special. Clean code so far.

Implementing business logic - uniformed approach

First, we need to extend our model in order to make it more interesting :) Our system must support handling user's payments related to Payment Period. The following requirements are added:

1) when Account is activated, Payment Period must be created that will be used to keep track of payments related to the Account

2) after Payment Period expires, subsequent Payment Period must be created, but expired Payment Period should still be accessible

We could model our Account like this:

class Account extends AbstractAggregateRoot {
    {...}
    @OneToMany
    private List<PaymentPeriod> paymentPeriods;

    private int currentPaymentPeriod;
    {...}
}

class PaymentPeriod {

  @ManyToOne
  private Account account;
  {...}
}

In this model, Account is responsible for managing Payment Periods. It sounds good, we can implement account activation inside Account class:

 
public void activate() {
  validateTransitionToStatus(ACTIVE)

  apply(new AccountActivatedEvent())

  // handle AccountActivatedEvent
  status = ACTIVE
  currentPaymentPeriod++;
  paymentPeriods.add(new PaymentPeriod(...))
}

Please notice three blocks of code in this method and theirs order. This separation is dictated by CQRS-based design. You should have all these blocks in every method that is invoked by Command Handler. The blocks are:

1) validation - checking if operation is allowed and will not break consistency of the Aggregate

2) raising event - creating a Domain Event containing information about Aggregate's change

3) handling event - updating state of the Aggregate (no exceptions, no logic here!)

Every change of Aggregate's state must be signaled with an Event (Domain Event). All Domain Events will be stored in Event Store (if configured) (just serialized as Blobs or Clobs to single table).

If our Aggregate Root is event-sourced (is reconstructed from Event Store instead or being created by EntityManager), we should move event handling code to separate method:

@EventHandler
private void accountActivated(AccountActivatedEvent event) {
  status = ACTIVE
  currentPaymentPeriod++;
}

We will not discuss Event Sourcing in this article, as we don't want to get rid of our powerful ORM, or do we? (actually in CQRS world ORM is persona non grata - you were warned ;)

Keep your ARs lously coupled

Going back to our model, after thinking a little bit longer, we realize that it doesn't fit well our needs... One of the requirements is to process commands related directly to Payment Periods. These commands should be dispatched directly to Payment Period entity rather than go through Account AR. Payment Period should be an AR on its own. When we think more about this (and talk with our Domain Expert (if we have one;)), the separation of Account and Payment Period will become even more obvious. We could easily imagine two services Account Service (responsible for accounts management) and Payment Service (responsible for payment registration) working independently.

So we can simplify Account AR and upgrade Payment Period to AR:

class Account extends AbstractAggregateRoot {
    {...}
    private int currentPaymentPeriod;

    public void activate() {
      validateTransitionToStatus(ACTIVE)

      apply(new AccountActivatedEvent())

      // handle AccountActivatedEvent
      status = ACTIVE
      currentPaymentPeriod++;
    }
    {...}
}

class PaymentPeriod extends AbstractAggregateRoot {
    {...}
    @ManyToOne
    private Account account;
    
    public PaymentPeriod(Account account) {
      apply(new PaymentPeriodCreated(account.getAggregateId()));
    }
    {...}
}

Now account activation is implemented partially (Payment Period is not being created). We could implement Application Service that would first call Account#activate and than create new Payment Period, but implementing business logic within Application Service layer leads to Transaction Script that we are trying to avoid (we want to avoid both ARs (Account and Payment Period) forcibly be invoked in the same transaction - it hurts system scalability). Lets think of our ARs on higher level. They belong to different contexts/services (virtual Account Service and Payment Service). The way to communicate between different contexts (services) is to use Domain Events!

Events to the rescue

We already have implemented raising of the AccountActivatedEvent in activate() method of Account AR. Now we must create Event Listener that will listen for this event and will send PaymentPeriodCreate command. With Axon it is as simple as creating new class:

 
@Component
public class PaymentService {

  @Autowired
  private CommandBus commandBus;

  @EventHandler
  public void createPaymentPeriodOnAccountActivation(AccountActivatedEvent event) {
    commandBus.dispatch(
      new PaymentPeriodCreateCommand(event.getAccountId())
    );
  }
}

Of course, we need to implement a command handler that will handle PaymentPeriodCreateCommand by creating Payment Period AR and adding it to Repository. Thats all. Now we have independent ARs that communicate with events. This design leads us in direction of autonomous components (services) communicating asynchronously in publish-subscribe model (aka: push integration model), possibly via some kind of EventBus or Broker (see: Avoid a Failed SOA: Business & Autonomous Components to the Rescue by Udi Dahan) But we will not go so far.

There are many other benefits from applying EDA. One of them is ability to keep detailed history of Events:

History of Events (Audit)

By storing Events in database (Event Store) we keep log of changes. We can easily create additional table containing following data:

aggregate root class
aggregate root id
event class
user

The table like this can serve basic reporting purposes. If we want to create more sophisticated reports in the future, we can reply events stored in Event Store and populate any report table we need. All history of changes is kept in Event Store.

Now lets see how we can model long running process with SAGA! In case you forgot the requirements, short reminder: new Payment Period must be created after the current one expires.

Enter SAGA

Saga is a stateful component (its state is persisted across invocations) that is capable of receiving events (including timeout events) (similar to Event Listener). Saga represents business process instance, in other words business process associated with particular AR(s).

 
class PaymentPeriodSaga extends AbstractSaga {

    @StartSaga
    @SagaEventHandler(associationProperty = "paymentPeriodId")
    public void paymentPeriodCreated(PaymentPeriodCreatedEvent event) {
        associateWith("accountId", event.getAccountId());
        getEventScheduler().schedule(
          // trigger datetime
          event.getValidityInterval().getEnd(), 
          // the event to publish
          new PaymentPeriodExpiredEvent(event.getContext(), event.getAggregateId())
            );
    }

    @SagaEventHandler(associationProperty = "paymentPeriodId")
    public void paymentPeriodExpired(PaymentPeriodExpiredEvent event) {
        RenewAccountCommand command = new RenewAccountCommand.Builder(event.getContext())
            .accountId(getAssociatedId("accountId"))
            .build();
        
        getCommandBus().dispatch(command);
    }
}

First method will be invoked on PaymentPeriodCreatedEvent and will result in creation of new Saga associated with Payment Period being created and related Account. Inside method body we schedule the PaymentPeriodExpiredEvent that will be triggered when validity interval of Payment Period ends (Axon provides Quartz-based implementation of Event Scheduler) . The second method is called when payment expiration happens (when PaymentPeriodExpiredEvent is triggered by the Event Scheduler). The only thing this method does is sending a command that will be processed by our Account Service (currentPaymentPeriod must be increased) and eventually by Payment Service (new Payment Period will be created).

Lets see how easy we can test our Saga with use of Test Fixture provided by Axon:

 
class PaymentPeriodSagaTest {
    AggregateIdentifier newPaymentPeriodId = ...
    AggregateIdentifier accountId = ...
    Interval validityInterval = new Interval(new DateTime(), new DateTime().plusDays(1));

    getFixture(PaymentPeriodSaga.class)
    // given
    .givenAggregate(newPaymentPeriodId)
      .published(new PaymentPeriodCreatedEvent(accountId, validityInterval))
    // when
    .whenTimeAdvancesTo(validityInterval.getEnd())
    // then
    .expectDispatchedCommandsEqualTo(
      new RenewPaymentPeriodCommand(accountId)
    );
}

Finally, I want to discuss one more topic related to DDD.

Don't pollute your core domain model

What is common mistake DDD beginners make is that they try to apply DDD totally (put all application logic into ARs boundaries). Let's take an example and add new requirement to our application: All entities (including Account) are separated by Sales Areas. Any operation on Account (creation, activation, etc.) can be performed only if the owning Sales Area is in status ACTIVE.

First, we will modify our model by adding the following JPA mapping to the Account AR:

 
class Account extends AbstractAggregateRoot {
    {...}
    @ManyToOne
    private SalesArea salesArea;
    private int currentPaymentPeriod;
    
    public void activate() {
    {...}
    }
}

Now lets think of the requirement. Where should we put the checking if the Sales Area is active? The activate() method of Account AR seems to be the perfect place. But if we think more, we realize that Sales Area does not belong to our core domain! Checking status of the Sales Area inside Account AR will pollute the code (checking must be done before any modification of Account's state). So our new model is broken! There should be no Account -> Sales Area mapping. But we can not remove it, because we reuse the same model for serving queries (we don't follow CQRS in this aspect) and we need to be able to filter Accounts by Sales Area easily. Ok, so the better place to put the checking would be a Command Handler (AccountCommandHandler). But it may be necessary to reuse this logic across different commands. What we need is some kind of interceptor that will prevent particular commands (account related or other) reaching Command Handlers. Not surprisingly Axon provides CommandHandlerInterceptor interface that allows for customized command handler invocation chains. No example this time, as it is quite easy to imagine:)

http://pkaczor.blogspot.com/2011/08/axon-framework-ddd-and-eda-meet.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

Bullshit Bingo - REST i RESTful

2011-02-25T00:00:00-08:00

Ostatnio nie mam trochę czasu na techniczne wpisy, także tym razem wpis będzie bardziej filozoficzny. Wczoraj zostałem zapytany o moją opinię na temat konwencji REST co zainspirowało mnie do stworzenia tego wpisu, ku przestrodze przed bezmyślnym wciskaniem tej architektury do każdej aplikacji.

REST w moim odczuciu urosło ostatnimi czasy do jednego z największych buzzwordów w świecie IT. Mało kto tak naprawdę rozumie tę architekturę, ale każda aplikacja, każdy serwis musi być REST-owy. Tak jakby od tego miało zależeć być albo nie być projektu. Być może w rozmowach biznesowych posiadanie REST-owej architektury jest na tyle przekonywującym argumentem, że łatwiej pozyskać sponsorów. Nie wiem. Ja jednak proponuję każdemu krytycznym okiem przyjrzeć się tej architekturze i samemu ocenić, czy w mojej aktualnej aplikacji jest ona w ogóle potrzebna? Czy nie jest tak, że generuje ona więcej problemów niż pożytku? Oto kilka problemów jakie można napotkać wdrażając architekturę REST-ową.

Id-ki, Id-ki widzę...

To co od razu rzuca się w oczy w architekturze REST-owej to wszędobylskie "Id-ki" w adresach URL. Pół biedy, jeżeli są to identyfikatory danych publicznych (np. ofert w sklepie), gorzej jak zaczynają się tam pojawiać identyfikatory zasobów, do których dostęp chcemy ograniczyć. A już szczytem masochizmu jest wrzucanie identyfikatorów profili użytkowników! Przykładowo edycja profilu użytkownika w naszej aplikacji może być dostępna pod takim URL-em:

/users/39/edit

No super! Piękny RESTful-owy URL. Z tym, że w kontrolerze dla takiego adresu i tak musimy zrobić walidację, że identyfikator użytkownika podanego w adresie URL jest taki sam jak identyfikator zalogowanego użytkownika! Inaczej mogli by oni edytować profile innych użytkowników. Także w tym przypadku użytkownik o identyfikatorze 39 i tak może wejść tylko na stronę podając parametr 39 w adresie URL, inaczej zostanie przekierowany na jakąś stronę informującą go, że nie ma dostępu do żądanego zasobu. Jaki zatem jest sens posiadania parametru w adresie URL, skoro i tak nie możemy go modyfikować? Nic nie zyskujemy, a możemy narazić się na kompromitację aplikacji gdy przez roztargnienie zapomnimy o walidacji albo ją przez przypadek wyłączymy. Czy nie lepiej byłoby mieć adres:

/users/edit

Albo jeszcze lepiej:

/edit_profile

I nie musieć martwić się o identyfikator podany w URL-u?

Sprawy tu mogą się jeszcze bardziej skomplikować. Wyobraźmy sobie, że chcemy użytkownikowi udostępnić stronę edycji zamówienia, które on złożył. Taka storna mogłaby być dostępna pod adresem:

/users/39/orders/10

W ten sposób sami sobie utrudniamy życie, bo nie dość, że musimy sprawdzać identyfikator użytkownika, to jeszcze musimy sprawdzić, że zamówienie o identyfikatorze 10 należy do użytkownika o identyfikatorze 39. W tej sytuacji o wiele lepsze jest wywalenie części dotyczącej użytkownika (która i tak jest stała):

/orders/10

Teraz sprawdzamy jedynie czy te zamówienie należy do zalogowanego użytkownika, którego identyfikator przechowujemy gdzieś w sesji (byle nie jawnie w pliku cookie ;)).

Także piersza zasada poprawnego implementowania REST-u mówi: wywal z URL-i stałe parametry, a w szczególności te, które dotyczą użytkowników.

No i warto zastanowić się nad jeszcze jedną kwestią. Czy te identyfikatory wnoszą cokolwiek użytecznego dla naszej aplikacji? Czy naprawdę uważamy, że użytkownicy będą przeglądać oferty poprzez modyfikowanie parametru ID w adresie URL? Moim zdaniem bardzo wątpliwe.

Ładne i brzydkie adresy URL

To co jest charakterystyczne w REST-owej architekturze to jej adresy URL tzw. pretty URL. No są one może i przyjazne, oraz nie kłują w oczy wszędobylskimi znakami ? oraz &. Problem pojawia się wtedy, kiedy nasza witryna dostaje się pod strzechy eskertów od SEO. Pierwsze co każą Ci zmienić w takiej aplikacji to właśnie adresy URL.

Stara zasada SEO mówi, że w adresie URL musi znaleźć się to do czego ta strona prowadzi. Przykładowo załóżmy, że poniższy adres prowadzi do strony oferty zakupu Mac Booka Pro (nie nie jestem funboyem Apple'a, nie mam ani Mac Booka, ani iPhone'a ani niczego innego z nadgryzionym jabłkiem w logo ;)):

/offers/131

Ekspert od SEO powie Ci "Panie, na taki URL to ty się nigdy nie wypromujesz, trzeba go będzie przepisać". No i z twojego pięknego URL-a robi się:

/oferty/131/Mac-Book-Pro

Także suma sumarum na końcu i tak będziesz musiał ręcznie te piękne URL-e przepisywać (albo zaimplementować sprytny sposób ich przepisywania coby nie robić tego ręcznie ;)) i nie będą one już takie piękne.

Pokaż mi swój identyfikator, a powiem ci jaką masz sprzedaż

Jest jeszcze jedna ciekawa osobliwość posiadania identyfikatorów w adresach URL. Otóż okazuje się, że mogą one udostępniać na zewnątrz informacje, którymi niekoniecznie chcielibyśmy się dzielić. Jeżeli przykładowo nasza strona pozwala podglądać publiczne profile użytkowników np. pod adresem:

/profiles/39

Inkrementując nasz identyfikator do momentu, aż otrzymamy 404 dowiemy się iluż zarejestrowanych użytkowników posiada dany portal (i autentycznie jest kilka takich portali gdzie to można zrobić, ale nie wymienię ich nazwy ;)).

W ten sposób możemy wyciągać z witryn informacje nie tylko o ilości zarejestrowanych użytkowników, ale i posiadanych ofert itd. Także trzeba być tego świadomym, że nie tylko to co jest na stronie jest informacją, ale i to co jest w adresie URL. I trzeba się zastanowić czy chcemy tę informacje upubliczniać. Może się skończyć na tym, że nasze REST-owe identyfikatory i tak będziemy zasłaniać jakimiś losowymi wartościami na podstawie których będziemy identyfikować zasób i w tym przypadku REST-owość może stać się bardziej uciążliwa niż pomocna.

Polimorfizm URL-i i metody HTTP

Konwencja REST-owa zbudowana jest na bazie czterech metod protokołu HTTP: GET, POST, PUT oraz DELETE. Już tutaj pojawia się pierwszy problem, gdyż przeglądarki internetowe z reguły wykorzystuję jedynie GET oraz POST. Stąd wszelkie formularze REST-owe do aktualizacji danych czy linki do ich usuwania muszą stosować różne sztuczki, aby zasymulować użycie metod PUT lub DELETE w żądaniach GET i POST. Czasami to stwarza problemy, zwłaszcza początkującym, przy konfiguracji routingów.

Konwencja ta niestety nie wyjaśnia do końca co powinno się dziać, jeżeli jakaś operacja się nie powiedzie. Przykładowo wchodzimy na ekran edycji złożenia zamówienia:

GET /orders/new

Konwencja REST mówi nam, iż utworzenie nowego zasobu (w tym wypadku o nazwie order) powinno zostać wykonane za pomocą metody POST ale pod adres kolekcji zasobów:

POST /orders

I taki adres będzie ukryty w naszym formularzu (w atrybucie action elementu form).

Takie działanie może i jest sensowne z punktu widzenia REST-a, ale z punktu widzenia działania witryny i przeglądarki internetowej jest wielce niepożadana. Dlaczego? Jeżeli nasz formularz jest nieprawidłowy nie chcemy lądować na stronie z listą, chcemy ponownie wyswietlić formularz wraz z odpowiednimi komunikatami o błędach. Innymi słowy nie chcemy być na /orders tylko ciągle na /orders/new. Niestety przeglądarka zmieni nam adres, mimo iż pozostajemy w tym samym miejscu. Jeszcze gorzej jest, jeżeli w ogóle nie udostępniamy strony o adresie /orders (czy chcemy użytkownikom udostępniać stronę z listą wszystkich zamówień złożonych w systemie?). Jeżeli użytkownik w tym momencie zrobi zakładkę, aby późiej powrócić i poprawić formularz zamiast formularza przywita go piękne 404, a przecież wcześniej był na tym formularzu i go wypełniał!

O tym problemie pisałem już kiedyś na moim blogu.

Parametrów kilka

Do tej pory skupiałem się na architekturze REST-owej w kontekście witryny internetowej. A co w przypadku serwisów webowych? Wydaje się, że architektura ta jest wręcz stworzona do takich serwisów. O ile człowiek nie będzie łaził po stronie manipulując identyfikatorami o tyle aplikacja korzystająca z serwisu nie będzie miała z tym problemu. Jednak w praktyce niekoniecznie wszystko wygląda tak różowo.

W całej swojej karierze deweloperskiej nie spotkałem jeszcze serwisu udostępniającego jakieś poważne usługi (np. płatności), którego żądania przyjmują tylko 1 parametr albo wcale. Zwykle takie żadania przyjmują kilka parametrów, a mi zdażało się pisać takie co przyjmowały 10-15 parametrów. I to wcale nie jest nic dziwnego! Oprócz samych parametrów żadania często wymagane są jakieś dane identyfikacyjne, jakieś tokeny, odciśki SSH czy dane statystyczne.

Wszystko to powoduje, że nasze piękne URL-e przestają być już piękne i nie ma w tym nic złego, w końcu te URL-e nie są przeznaczone dla ludzi. Maszyny, przynajmniej jak na razie, nie mają zmysłów ani gustów i im nie przeszkadzają takie długie adresy. W związku z tym jaki sens jest upierać się przy REST-owości w takich serwisach?

A morał jest krótki i niektórym znany...

Ok, czy to oznacza, iż architektura REST jest zła i nie powinno się z niej korzystać? Nie, absolutnie nie! Trzeba tylko umieć rozgraniczyć, kiedy architektura REST jest naprawdę potrzebna i sensowna, a kiedy jest tylko zwyczajnym buzzwordem. Trzeba być świadomym tego, co taka architektura ze sobą przynosi i czy w naszej aplikacji będzie ona miała zastosowanie i będzie w ogóle wykorzystywana.

Obecnie wszystkie projekty muszą być REST-owe, musi być JSON i musi być coś z Enterprise w nazwie. Ta buzzwordowa karuzela już bardziej działa na nerwy niż przynosi coś sensownego, ale co zrobić, prawa marketingu są nieubłagane i aby mieć inwestorów trzeba wykazać się innowacyjnością, nawet za cenę funkcjonalności, bezpieczeństwa czy łatwości programowania i utrzymania. Ja osobiście REST i RESTful dokładam do swojej listy Bullshit Bingo i Tobie też polecam zastanowienie się nad tym, czy faktycznie ten REST jest Ci potrzebny w Twojej aplikacji, aby potem na spotkaniu ktoś nie wstał i nie zawołał Bullshit!

http://michalorman.pl/blog/2011/02/bullshit-bingo-rest-i-restful/

Autor: Michał Orman

Programista, konsultant IT. Pasjonuje się nowoczesnymi technologiami i metodami wytwarzania oprogramowania, oraz pedantycznie dba o jakość kodu w swoich projektach. Obecnie poświęca swój czas na zgłębianie tajników korporacyjnej Javy EE oraz frameworka Ruby on Rails, a zawodowo zajmuje się szeroko pojętym konsultingiem.

JPA - stronicowanie wyników kwerendy

2011-02-23T00:00:00-08:00

Interfejs kwerendy zdefiniowany w JPA (javax.persistence.Query) umożliwia stronicowanie listy wyników (paging). Służą do tego metody:

setFirstResult(int startPosition)
setMaxResults(int maxResult)

Wynikiem kwerendy ze stronicowaniem jest podzbiór obiektów czyli strona, której numer i rozmiar określają odpowiednio parametry startPosition i maxResult. Stronicowanie przyspiesza działanie aplikacji (mniejsza ilość danych do przetwarzania) oraz ułatwia użytkownikowi nawigację i wyszukiwanie określonych rekordów. Jednak jak to zwykle w świecie ORM bywa, każde rozwiązanie ma swoje "problemy", które w przypadku stronicowania objawiają się wraz z użyciem mechanizmu ładowania wyprzedzającego elementów kolekcji.

Ładowanie wyprzedzające ze stronicowaniem

Ładowanie wyprzedzające generalnie polega na wykonaniu kwerendy w taki sposób, aby razem z głównymi obiektami pobrane zostały obiekty powiązane (pojedyncze obiekty bądź kolekcje). Najbardziej popularnym sposobem ładowania wyprzedzającego jest złączenie tabel w kwerendzie (join fetching). Niestety, metoda ta nie nadaje się do zapytań ze stronicowaniem. Zobaczmy dlaczego.

Przykład

Mamy obiekt zamówienia (Order) zawierający pozycje (LineItem):

@Entity
public class Order {
  // ... ...
  @OneToMany
  private List<LineItem> lineItems;

 @Temporal(DATE)
 private Date orderDate;
}

Załóżmy, że chcemy wyświetlić użytkownikowi stronę z listą zamówień. Jednocześnie dla każdego zamówienia chcemy załadować jego pozycje. W tym celu tworzymy kwerendę na obiekcie Order, ze stronicowaniem oraz ze złączeniem kolekcji lineItems:

Query query = em.createQuery("SELECT o FROM Order o LEFT JOIN FETCH o.lineItems");
query.setFirstResult(1);
query.setMaxResults(3);
List<Order> page = query.getResultList();

Złączenie definiujemy w JPQL za pomocą klauzuli JOIN FETCH.

Oczekiwania wobec dostawcy JPA

Załóżmy, że w bazie mamy 3 zamówienia z różną ilością pozycji. Oczekujemy, że zarządca utrwalania (EntityManager) wykona pojedyncze zapytanie sql (z klauzulą left outer join) i zwróci listę zawierającą 3 obiekty Order. Dodatkowo oczekujemy, że w każdym obiekcie Order, kolekcja lineItems będzie załadowana.

Realizacja

Hibernate

Hibernate co prawda zwraca oczekiwany wynik, ale generuje podejrzanie brzmiący komunikat: firstResult/maxResults specified with collection fetch; applying in memory!

EclipseLink

EclipseLink zwraca 2 obiekty Order.

Wyjaśnienie

Aby zrozumieć co się stało, zobaczmy jak dokładnie wygląda wynik naszej kwerendy na poziomie rekordów bazy danych bez uwzględnienia stronicowania:

order_id	line_id	cust_name	sku
1	1	Jan Kowalski	232342342
1	2	Jan Kowalski	345345443
2	3	Paweł Kaczor	655624323
3	4	Jerzy Dudek	673454345
3	5	Jerzy Dudek	563425676
3	6	Jerzy Dudek	234576854

Widzimy, że w wyniku złączenia, otrzymujemy zbiór rekordów liczebnością przekraczający ilość zamówień. Jeśli z takiego zbioru będziemy chcieli wyciągnąć stronę o rozmiarze 3, otrzymamy tylko pierwsze trzy rekordy zawierające zamówienia z id 1 i 2. Zamówienie z id 3 zostanie wykluczone. Otrzymamy zatem dwa zamówienia zamiast trzech! Wniosek: stronicowanie na poziomie rekordów w kwerendzie ze złączeniem outer join jest niedokładne.

Teraz już wiemy dlaczego EclipseLink zwrócił dwa zamówienia. Ale jakim sposobem Hibernate zwrócił trzy zamówienia? Odpowiedź jest prosta (ale bolesna). Hibernate omija problem poprzez załadowanie wszystkich rekordów z tabeli i wyselekcjonowanie strony w pamięci (stąd magiczne: "applying in memory"!). Rozwiązanie to zwiększa zużycie zasobów (procesora i pamięci), co przeczy głównemu celowi (zwiększeniu wydajności), dla którego stosujemy stronicowanie. Należy poszukać lepszego rozwiązania.

Ładowanie wsadowe ze stronicowaniem

Ładowanie wsadowe (batch fetching) to bardziej zaawansowany sposób pobierania wyprzedzającego. Obiekty powiązane nie są ładowane w kwerendzie głównej, ale w dodatkowej kwerendzie, której ostateczna postać zależy od wybranego (o ile dostawca na to pozwala) typu ładowania wsadowego.

Stronicowanie wykonywane jest bezproblemowo w kwerendzie głównej, która nie zawiera klauzuli outer join.

Konfiguracja - Hibernate

Dla kolekcji lineItems specyfikujemy ładowanie wsadowe używając adnotacji @org.hibernate.annotations.BatchSize:

@OneToMany
@BatchSize(size = 20)
private List<LineItem> lineItems;

Parametr size w adnotacji @BatchSize oznacza ilość elementów kolekcji, jaka zostanie załadowana w pojedynczej kwerendzie sql.

Konfiguracja - EclipseLink

Ten sam sposób ładowania wsadowego konfigurujemy w EclipseLink następująco:

@OneToMany
@BatchFetch(BatchFetchType.IN, size = 20)
private List<LineItem> lineItems;

Realizacja

Tworzymy kwerendę JPA tym razem bez klauzuli JOIN FETCH. W celu lepszego zobrazowania działania pobierania wsadowego, dodajemy warunek na pole orderDate.

Query query = em.createQuery("SELECT o FROM Order o WHERE o.orderDate = CURRENT_DATE");
query.setFirstResult(1);
query.setMaxResults(3);
List<Order> page = query.getResultList();

Wygenerowane zostają dwa zapytania sql:

kwerenda główna zamówień (ze stronicowaniem)

SELECT * 
FROM Order o
WHERE o.ORDER_DATE = ? LIMIT ? OFFSET ?

kwerenda dodatkowa - załadowanie wsadowe pozycji zamówień

SELECT *
FROM Order o, LineItem li 
WHERE o.ID = li.ORDER_ID AND li.ORDER_ID IN (?,?)

Jak widzimy, w celu załadowania pozycji tylko dla zamówień pobranych w kwerendzie głównej, w kwerendzie dodatkowej została użyta klauzula IN.

Optymalizacja - EclipseLink

EclipseLink pozwala skonfigurować trzy typy pobierania wsadowego: (IN, JOIN, EXISTS) Typ IN już znamy. Mankamentem jest tutaj ograniczona ilość elementów kolekcji, które mogą być załadowane w jednej kwerendzie sql. Efektywniejszym rozwiązaniem jest użycie kryteriów selekcji z kwerendy głównej w kwerendzie dodatkowej (typ JOIN - "The original query's selection criteria is joined with the batch query").

Konfiguracja:

@OneToMany
@BatchFetch(BatchFetchType.JOIN)
private List<LineItem> lineItems;

Wygenerowana kwerenda dodatkowa wygląda następująco:

SELECT *
FROM Order o1, Order o2, LineItem li 
WHERE o1.ID = li.order_id AND (o2.ID = li.order_id AND o1.ORDER_DATE = ?)

Widzimy, że problematyczna klauzula IN zastąpiona została kryterium wyboru identycznym jak w kwerendzie głównej.

Podsumowanie

W powyższym artykule przedstawiłem w jaki sposób stosować stronicowanie (paging) w kwerendach JPA. Szczegółowo omówiłem problem stronicowania, kiedy w kwerendzie używane jest ładowanie wyprzedzające elementów kolekcji.

http://pkaczor.blogspot.com/2011/02/jpa-stronicowanie-wynikow-kwerendy.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

Mockowanie z użyciem Spring i Mockito

2011-01-03T00:00:00-08:00

W poniższym wpisie chciałbym przedstawić jak efektywnie skonfigurować testy integracyjne w Spring z użyciem mocków.

Testy integracyjne w Spring

Tworzenie i uruchamianie testów integracyjnych w Spring jest dziecinnie proste dzięki dobrodziejstwom jakie dostarcza Spring TestContext Framework. Zakładając, że plik xml konfiguracji kontekstu aplikacji Spring (Spring Application Context) w module aplikacji, który chcemy testować, nazwaliśmy applicationContext.xml, uruchomienie testu integracyjnego JUnit dla takiego moduły wygląda następująco:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {
        "classpath:applicationConfig.xml" 
})
public class DoSthTest {

@Test
public void shouldDoSth() {}

}

Jest to najprostszy sposób na przetestowanie poprawności pliku konfiguracji kontekstu aplikacji, w którym zdefiniowane są zależności pomiędzy klasami zarządzanymi przez Spring.

No dobrze, ale chcemy przetestować konkretny serwis, który stworzyliśmy. Zatem do naszego testu wstrzykujemy serwis i tworzymy dla niego metodę testującą:

@Autowired
private DoSthService serviceToTest 

@Test
public void shouldReturnSth() {
    // when
    Object result = serviceToTest.doSth();
    
    // then
    assertNotNull(result)
}

Tworzenie mocka

Nasz serwis korzysta z kilku innych serwisów, w tym z serwisu HttpClient, który w naszym teście musimy zastąpić mockiem. Jednym ze sposobów jest ręczna zmiana zależności w kodzie testu:

@Test
public void shouldReturnSth() {
    // given
    HttpClient mockHttpClient = Mockito.mock(HttpClient.class);
    serviceToTest.setHttpClient(mockHttpClient);
    ...
}

Sposób ten ma jednak kilka wad:

Dla każdego testu (metody testującej) musimy sami tworzyć i przypisywać mocka
Serwis musi dostarczać settera dla zależności mockowanej, podczas gdy w przypadku wstrzykiwania zależności za pomocą adnotacji setter nie jest wymagany
Mockujemy tylko konkretną zależność między dwoma beanami. Jeżeli serwis który mockujemy jest używany przez inny serwis biorący udział w teście (np. DoSthService używa HttpClient i OtherService, a OtherService używa HttpClient) , musimy mockować każdą zależność osobno

Lepszym rozwiązaniem jest podmiana serwisu HttpClient bezpośrednio w kontekście aplikacji. Oczywiście nie możemy zmienić pliku applicationContext.xml, musimy stworzyć odrębny kontekst aplikacji i wskazać go w konfiguracji naszego testu:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(locations = {
        "classpath:applicationConfig-test.xml" 
})
public class DoSthTest {

@Test
public void shouldReturnSth() {
    // when
    Object result = serviceToTest.doSth();
    ...
}
}

No dobrze, ale jak stworzyć mocka w pliku konfiguracji kontekstu aplikacji, skoro nasz mock nie jest utworzoną przez nas osobną klasą, ale został wygenerowany automatycznie przez framework Mockito ( Mockito.mock(HttpClient.class) ) ?

Rozwiązanie jest proste. Metodę Mockito.mock należy zadeklarować jako metodę fabrykującą naszego mocka podając jako argument tej metody klasę obiektu mockowanego:

<bean id="httpClient" class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="org.apache.http.client.HttpClient"/> 
</bean>

Dostrajanie konfiguracji

Kopiowanie całej konfiguracji kontekstu aplikacji w celu nadpisania jednego serwisu prowadzi do redundancji kodu (kodu konfiguracji), a zatem zwiększa koszt utrzymania aplikacji. Jeżeli chcemy tego uniknąć, możemy zdefiniować dwa pliki konfiguracji kontekstu aplikacji w konfiguracji naszego testu:

@ContextConfiguration(locations = {
        "classpath:applicationConfig.xml", 
        "classpath:applicationConfig-test.xml" 
})
public class DoSthTest {
...
}

W pliku applicationConfig-test.xml definiujemy tylko mocki, które zastąpią istniejące beany w konfiguracji głównej. Zwróćmy uwagę na kolejność deklaracji plików konfiguracji. Ważne jest aby deklaracja pliku konfiguracji mocków następowała po deklaracji pliku głównego konfiguracji.

Autowstrzykiwanie mocków

W przypadku gdy korzystamy z autowstrzykiwania zależności, nasz mock będzie dostępny tylko gdy wstrzykiwanie zależności odbywa się na podstawie nazwy. A zatem mock nie zostanie znaleziony jeśli używamy adnotacji @Autowired, dla której wstrzykiwanie odbywa się na podstawie typu. Rozwiązaniem może być dodanie kwalifikatora wskazującego nazwę zależności:

@Autowired
@Qualifier(value="httpClient")
private HttpClient httpClient;

Jednak lepszym rozwiązaniem jest zastosowanie adnotacji @javax.annotation.Resource. W tym przypadku zależność najpierw wyszukiwana jest po nazwie, a w przypadku braku pasującej nazwy, po typie.

Włączanie/wyłączanie mocków

Czasami ten sam test integracyjny chcemy uruchamiać zarówno z serwisem w postaci mocka jak i z serwisem rzeczywistym. Jeśli stosujemy opisaną powyżej metodę nadpisywania beanów z konfiguracji głównej mockami z konfiguracji testowej, włączenie/wyłączenie mocka można łatwo osiągnąć modyfikując plik konfiguracji mocków (dodając bądź usuwając mocka). Jednak co z kodem sterującym zachowaniem mocka (patrz kod poniżej)?

@Autowired
private DoSthService serviceToTest 

@Resource
private HttpClient httpClient;

@Test
public void shouldReturnSth() {
    // given
    //httpClient must be a mock!
    given(httpClient.execute(any(HttpUriRequest.class)))
        .willReturn(myResponse);

    // when
    Object result = serviceToTest.doSth();
    ...
}

Uruchomienie tego kodu na obiekcie nie będącym mockiem zakończy się wyjątkiem. Należy zatem kod sterujący mockiem wykonać warunkowo tylko jeśli obiekt rzeczywiście jest mockiem. Sprawdzenie implementujemy następująco:

// given
if (!httpClient.getClass().isAssignableFrom(HttpClient.class)) {
    given(httpClient.execute(any(HttpUriRequest.class)))
        .willReturn(myResponse);
}

Współdzielenie mocków

Jeżeli chcielibyśmy użyć tego samego mocka w kilku metodach testowych musimy pamiętać o zresetowania stanu mocka przed każdym testem. Najprostszym rozwiązaniem jest dodanie do klasy testu metody resetMocks z adnotacją @org.junit.Before:

@Before
public void resetMocks() {
    Mockito.reset(httpClient);
}

Mockowanie częściowe

Na koniec przedstawię w jaki sposób utworzyć w konfiguracji kontekstu aplikacji częściowego mocka, czyli obiekt, którego zachowanie tylko w części chcemy mockować (np. zmieniając tylko rezultat wywołania metody):

  <bean id="httpClient" class="org.apache.http.client.HttpClient"/>
    <bean id="httpClientPartiallyMocked" class="org.mockito.Mockito" factory-method="spy">
        <constructor-arg ref="httpClient" /> 
    </bean>

W tym przypadku tworzymy mocka przy pomocy metody fabrykującej Mockito.spy, podając jako argument tej metody referencję do istniejącego bean-a.

http://pkaczor.blogspot.com/2010/12/mockowanie-przy-uzyciu-spring-i-mockito.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

Spring DM - czyli Spring i OSGi

2010-12-09T00:00:00-08:00

Uff, ale dawno nie wrzuciłem żadnego posta na bloga. Czas nadrobić nieco zaległości, a ostatnie tygodnie stały u mnie pod znakiem Spring'a. Obecnie przyglądam się integracji tego frameworka z ciekawą technologią OSGi, która ostatnio staje się coraz bardziej modna. Spring w swojej rodzinie frameworków posiada jeden o nazwie Spring Dynamic Modules, który służy do integracji komponentów Spring'owych z platformą OSGi (i na odwrót).

Krótko o platformie OSGi

Jak dotąd platforma Java nie dorobiła się porządnego wsparcia dla modularnych aplikacji. Oczywiście istnieją wzorce pozwalające nam na modularyzację aplikacji, jednakże z punktu widzenia maszyny wirtualnej jest to wciąż jedna, monolityczna aplikacja. Czego zatem brakuje Javie, do pełnej modularyzacji?

Jasnej definicji tego, czym jest moduł.
Określania zakresu widoczności modułu dla innych modułów.
Określenia cyklu życia modułu.
Określenia sposobów interakcji modułów.

Jak łatwo się domyśleć technologia OSGi została opracowana w celu wypełnienia tej niszy i oferuje platformę, która zapewnia nam funkcjonalności, których brakuje w standardowej Javie.

To co oferuje nam OSGi to lekką platformę dla komponentowych, oraz zorientowanych na usługi aplikacji w ramach wirtualnej maszyny Javy (JVM). Możemy dynamicznie, w czasie działania aplikacji, modyfikować rejestr komponentów (bundle - w terminologii OSGi) dodając nowe i podmieniając istniejące komponenty. Platforma OSGi zapewnia nam pełną izolację komponentów, dzięki czemu mamy pewność, że nie będą one przeszkadzały sobie nawzajem (np. poprzez konflikty wersji zależnych bibliotek JAR).

Krótko o Spring DM

Spring Dynamic Modules łączy technologię Spring z platformą OSGi. Framework ten nie przynosi żadnej dodatkowej funkcjonalności dla OSGi a jedynie obserwuje rejestrowane komponenty tworząc dla nich Spring'owe konteksty aplkiacji. Framework ten potrafi udostępnić komponenty Spring'owe jako komponenty OSGi (widoczne dla innych komponentów OSGi), oraz dowolny komponent OSGi, nawet nie Spring'owy, zainstalować w kontenerze Springa.

Integracja Spring'a z OSGi

No dobra, starczy tej teorii, zobaczmy jak wygląda integracja tych platform w kodzie.

Będziemy potrzebować dwóch komponentów, z których jeden będzie dostarczał usługę, a drugi z niej korzystał. Oba komponenty utworzone zostaną jako osobne komponenty OSGi.

Najpierw musimy określić interfejs dla naszej usługi:

public interface AuthorizationService {
    boolean authorize(String username, String password);
}

Teraz możemy utworzyć trywialną implementację tego interfejsu:

public class DefaultAuthorizationService implements AuthorizationService {
    public boolean authorize(String username, String password) {
        return "foo".equals(username) && "secret".equals(password);
    }
}

Kolejny krok to utworzenie konfiguracji Spring'owej. Framework Spring DM wymaga, aby taka konfiguracja znajdowała się w katalogu META-INF/spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:osgi="http://www.springframework.org/schema/osgi"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd">

    <context:component-scan base-package="demo.springdm" />

    <osgi:service interface="demo.springdm.api.AuthorizationService">
        <bean class="demo.springdm.api.impl.DefaultAuthorizationService" />
    </osgi:service>

</beans>

Najważniejszym elementem tej konfiguracji jest <osgi:service>, który deklaruje Springowy komponent jako komponent OSGi widoczny dla innych komponentów zainstalowanych w ramach tej platformy. Spring DM za nas zainstaluje komponent w rejestrze usług (ang. service registry) platformy OSGi przez co stanie się on dostępny dla innych komponentów.

Ok, moduł dostarczający usługe jest gotowy, teraz możemy przejść do modułu korzystającego z usługi. Utwórzmy zatem komponent Spring'owy do którego wstrzykniemy komponent zainstalowany w platformie OSGi:

@Component
public class AuthorizationClient {
    @Autowired
    private AuthorizationService authorizationService;

    @PostConstruct
    public void authorize() {
        System.out.println("Authorization for foo:bar : " + authorizationService.authorize("foo", "bar"));
        System.out.println("Authorization for foo:secret : " + authorizationService.authorize("foo", "secret"));
    }
}

Jak widać, jest to typowa klasa POJO z kilkoma adnotacjami typowymi dla Spring'a. Nic magicznego się tutaj nie dzieje. Aby kod ten działał potrzebujemy jednak komponentu authorizationService:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:osgi="http://www.springframework.org/schema/osgi"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-1.2.xsd">

    <context:component-scan base-package="demo.springdm" />

    <osgi:reference id="authorizationService" interface="demo.springdm.api.AuthorizationService" />

</beans>

W tym wypadku importujemy komponent OSGi jako komponent Spring'owy za pomocą <osgi:reference>.

Teraz pozostaje już tylko zainstalowanie komponentów w kontenerze OSGi (ja korzystam z Equinoxa):

$ java -jar org.eclipse.osgi_3.6.1.R36x_v20100806.jar -console

osgi> ss

Framework is launched.

id    State       Bundle
0     ACTIVE      org.eclipse.osgi_3.6.1.R36x_v20100806
1     ACTIVE      org.springframework.osgi.io_2.0.0.M1
2     ACTIVE      org.springframework.osgi.core_2.0.0.M1
3     ACTIVE      org.springframework.osgi.extender_2.0.0.M1
4     ACTIVE      org.springframework.aop_3.0.5.RELEASE
5     ACTIVE      org.springframework.asm_3.0.5.RELEASE
6     ACTIVE      org.springframework.beans_3.0.5.RELEASE
7     ACTIVE      org.springframework.context_3.0.5.RELEASE
8     ACTIVE      org.springframework.context.support_3.0.5.RELEASE
9     ACTIVE      org.springframework.core_3.0.5.RELEASE
10    ACTIVE      org.springframework.expression_3.0.5.RELEASE
11    ACTIVE      com.springsource.org.aopalliance_1.0.0
12    ACTIVE      com.springsource.net.sf.cglib_2.1.3
13    ACTIVE      com.springsource.slf4j.api_1.6.1
                  Fragments=15
14    ACTIVE      com.springsource.slf4j.org.apache.commons.logging_1.6.1
15    RESOLVED    com.springsource.slf4j.nop_1.6.1
                  Master=13
16    ACTIVE      com.springsource.ch.qos.logback.core_0.9.24
17    ACTIVE      com.springsource.ch.qos.logback.classic_0.9.24

osgi> install file:bundles/spring-demo/spring-dm-demo-producer-1.0.jar
Bundle id is 18

osgi> start 18 

osgi> install file:bundles/spring-demo/spring-dm-demo-consumer-1.0.jar
Bundle id is 19

osgi> start 19

osgi> Authorization for foo:bar : false
Authorization for foo:secret : true

osgi> ss

Framework is launched.

id    State       Bundle
0     ACTIVE      org.eclipse.osgi_3.6.1.R36x_v20100806
...
18    ACTIVE      demo.springdm.spring-dm-demo-producer_1.0.0
19    ACTIVE      demo.springdm.spring-dm-demo-consumer_1.0.0

Działa. Pierwsza integracja Spring'a z OSGi za pomocą frameworka Spring Dynamic Modules gotowa.

Podsumowanie

Platforma OSGi ma na celu wypełnienie luki jaka istnieje w Javie dotyczącej wsparcia dla aplikacji wielomodułowych. To co oferuje nam Java, czyli różne typy archiwów (JAR, WAR czy EAR) okazują się niewystarczające. OSGi jasno definiuje czym jest moduł, jaki jest jego cykl życia oraz izoluje moduły od siebie udostępniając tylko te usługi, które trzeba.

Spring Dynamic Modules to framework, który pozwala instalować komponenty Springo'we w kontenerze OSGi a także używać dostępnych komponentów i wstrzykiwać je do komponentów Springa. Całość dzieje się jedynie z pomocą odrobiny deklaracji w plikach XML-owych.

Działający kod aplikacji powstałej do tego posta można znaleźć pod adresem: https://github.com/michalorman/michalorman.github.com/tree/master/przyklady/spring-dm-czyli-spring-i-osgi

Znajduje się tam także Equinox skonfigurowany pod Spring DM 2.0.0.M1 oraz Spring'a 3.0.5.RELEASE (a nie 3.0.0.RC1 z jaką domyślnie jest Spring DM).

http://michalorman.pl/blog/2010/12/spring-dm-czyli-spring-i-osgi/

Autor: Michał Orman

jQuery - czyste szablony HTML

2010-11-04T00:00:00-07:00

Ta historia będzie o jquery pure templates - czyste wzorce HTML w jquery.

This article is also available in english version (see link at the bottom of this article).

Podczas pisania kodu na nowym projekcie znalazłem świetną bibliotekę Pure napisaną przez BeeBole i miałem właśnie o niej pisać. Ale wraz z użyciem jej znajdowałem coraz więcej problemów. Najpierw chciałem naprawić tą bibliotekę, ale w środku debugowania okazało się to nie takie proste, 20 kilobajtów źródeł ciężko zmienić.

Zdecydowałem się więc napisać swoją bibliotekę opisującą podobną ideę, ale wykorzystując inne podejście. Moja biblioteka jest nadal czysta, nie wymaga jednak śmiesznych znaczników HTML żeby wypełnić go danymi, wystarczy napisać kod który zawiera selektory jquery. Moja pierwsza próba została wykonana z użyciem selektorów jquery bezpośrednio w definicji danych:

data = {'a#my':"my url",'a#my@href':"#/url"}

Po napisaniu działającego kodu wzorcowego tylko w 3 godziny pomyślałem że dobrze by było mapować klucze z danych na selektory w jquery, tak żeby serwer nie musiał zwracać selektorów jako kluczy w JSON:

data2 = {'name':"my url",'link':"#/url"}

Do tego potrzebna jest prosta mapa:

map2 = {'name':'a#my','link':'a#my@href'}

Więc jak to uruchomić ? Proste :). Załącz bibliotekę w swoim kodzie (najlepiej w nagłówku):

<script src="jquery-pure-template.js" type="text/javascript" charset="utf-8"></script>

I wywołaj render na elementach wybranych przez jquery:

$('.user').render(data);

Lub używając mapy:

$('.user').render(data2,{map:map2});

Do działania potrzebny jest wzorzec (template) HTML:

<div class="user"><a href="#"></a></div>

na koniec otrzymamy oto taki wynik w HTML:

<div class="user"><a href="#/url">my url</a></div>

To był prosty przykład, ale ta biblioteka działa także z tablicami oraz zagnieżdżonymi tablicami, po prostu dajcie temu szanse, i pamiętajcie: nie zmuszajcie HTML do określania logiki, niech dane posterują logiką nie widok.

Oczywiście założone rozwiązanie może mieć kilka problemów, najważniejszy to wydajność. Tablice powyżej 500 elementów zaczynają zwalniać, ale używając zagnieżdżonych tablic można spokojnie operować na 5000 elementów na w miarę nowoczesnym komputerze. Dodatkowo dodanie id do zbiorów może przyśpieszyć kod nawet o 20% (znajdowanie elementów przez jquery).

Wiem że istnieją szybsze rozwiązania, które mogą bez problemu wyświetlić duże ilości danych, ale moje jest proste, tylko 70 linii kodu, to czyni je niesamowicie prostym w utrzymaniu i modyfikacji. Łatwiej pracować z mniejszą ilością kodu :).

http://niczsoft.com/2010/11/jquery-pure-templates/

Autor: Michał Papis

Programista, konsultant IT, administrator. Pasjonuje się programowaniem oraz administracja systemami (Linux). W wolnym czasie zajmuje się zdobywaniem wiedzy z zakresu IT, a szczególnie programowania. Obecnie realizuje projekty najczęściej używając frameworków Ruby on Rails oraz jQuery.

ZK - Ajax dla każdego

2010-10-29T00:00:00-07:00

ZK opiera swoją architekturę na technologii Ajax. Komunikacja klient-serwer z wykorzystaniem Ajax-a w całości realizowana jest przez silnik ZK i jest niewidoczna/przezroczysta z punktu widzenia aplikacji używającej ZK. To framework decyduje kiedy wysłać żądanie do serwera oraz kiedy i jakie elementy strony odświeżyć. Dodając do tego warstwę komponentów i zdarzeń, którą dostarcza ZK, otrzymujemy interfejs programistyczny znany z frameworków desktopowych (np. Swing). Mamy zatem obiekt kontrolera, którego metody wywoływane są w wyniku akcji użytkownika oraz komponenty GUI, którymi kontroler steruje. Kontroler może bezpośrednio wywoływać metody komponentów, bądź modyfikować obiekty modelu, z których komponenty GUI korzystają. Zarówno komponenty GUI jaki i obiekty modelu definiują zdarzenia jakie wysyłają w wyniku akcji użytkownika bądź wykonania określonego kodu. Tworzenie aplikacji w ZK nie różni się zatem znacząco od tworzenia aplikacji desktopowej. Co więcej, ZK oferuje nowoczesne rozwiązania niedostępne w starszych technologiach takich jak Swing (np. wbudowany data binding, język tworzenia interfejsu użytkownika oparty na XUL.

Tyle teorii, zobaczmy jak wygląda kod aplikacji opartej o ZK analizując konkretne przykłady.

Ajax w akcji

class PersonListCtrl extends GenericForwardComposer {

 //GUI components autowired by ZK
 private Listbox personsList;
 private Textbox firstName;
 private Combobox color;
 private Checkbox married;

 public void onAddPerson(Event event) {
  Person personBean = new Person();
  personBean.setFirstname(firstName.getValue());
  personBean.setColor(color.getValue());
  personBean.setMarried(married.isChecked());
  //save person to database and add it to the listbox
  ...
  addPersonRecord(personBean);
 }

 public void addPersonRecord(Person person) {
  Listitem newPersonItem = new Listitem(person.getName());
  List items = Listbox.geItems();
  items.add(newPersonItem);
  ...
 }
}

W powyższym przykładzie kontroler w metodzie obsługującej zdarzenie onAddPerson tworzy obiekt osoby (obiekt klasy Person) i wypełnia go danymi wprowadzonymi na stronie przez użytkownika. Dane te odczytywane są bezpośrednio z komponentów GUI (textbox, combobox, checkbox). ZK umożliwia wstrzyknięcie komponentów GUI do kontrolera na podstawie zgodności nazwy zmiennej w kontrolerze i atrybutu id komponentu GUI. Po zapisaniu obiektu osoby do bazy, wywoływana jest metoda addPersonRecord, w której nazwa osoby (String) dodawana jest do listy wyświetlanej na ekranie (komponent personsList klasy Listbox). Rezultatem modyfikacji komponentu Listbox będzie odświeżenie listy na stronie przeglądarki. Dzięki technologii Ajax odświeżony zostanie tylko fragment strony zawierający listę osób. Jak widać, mechanizm odświeżania działa automatycznie i nie wymaga żadnej ingerencji ze strony obiektu kontrolera.

Inteligentny model

Komponenty GUI przeznaczone do wyświetlania/edycji danych (listbox, combobox, grid, tree) mogą być powiązane z zewnętrznym obiektem modelu przechowującym dane. Rezultatem użycia modelu jest odseparowanie logiki związanej z tworzeniem/modyfikacją danych od logiki ich wyświetlania (zgodnie z wzorcem MVC). Dla komponentu Listbox przewidziano interfejs ListModel i dostarczono wiele implementacji tego interfejsu przeznaczonych do obsługi różnych typów kolekcji np. ListModelArray, ListModelList, ListModelSet, ListModelMap. Po przypisaniu modelu do listy, kontroler nie musi odwoływać się bezpośrednio do komponentu listy. Wszelkie operacje (dodanie, usunięcie elementu, zmiana selekcji) dokonuje na obiekcie modelu:

public void addPersonRecord(Person person) {
  ListModelList model = getModel();
  model.add(person)
}

Model w momencie modyfikacji (dodanie/usunięcie elementu) generuje zdarzenie, w którym zawarta jest szczegółowa informacja o zaistniałej zmianie. Komponent listy posiada obiekt nasłuchujący na zdarzenia pochodzące z modelu, dzięki czemu jest informowany o tym kiedy i w jakim zakresie musi dokonać odświeżenia swojego stanu. Modyfikacje w warstwie modelu są zatem automatycznie odzwierciedlane na stronie (w przeglądarce).

Widok

Logiką wyświetlenia danych dostarczonych przez model zajmuje się renderer. W naszym przykładzie metoda render, którą musi zaimplementować renderer listy wygląda następująco:

@Override
public void render(Listitem item, Object data) throws Exception {
  String personName = ((Person)data).getName();
  item.setLabel(personName);
}

Tworzenie własnego renderera zwykle nie jest jednak konieczne. Prostszą i efektywniejszą metodą jest użycie mechanizmów bindowania w kodzie strony:

<listbox model="@{controller.model}">
    <listitem self="@{each='person'}" label="@{person.name}"/>
</listbox>

Stosując data binding w wygodny sposób tworzymy powiązanie między komponentami GUI i danymi z modelu, które te komponenty mają wyświetlać. W podanym przykładzie lista nie jest skomplikowana, wyświetla bowiem tylko nazwę osoby. Jednak stworzenie bardziej skomplikowanej listy (np. dodanie większej ilości kolumn, zagnieżdżenie w wierszu innych komponentów) nie stanowi najmniejszego problemu. Przykład poniżej:

<listbox model="@{controller.model}">
 <listitem self="@{each='person'}">
  <listcell label="@{person.name}"/>
  <listcell>
   <combobox value="@{person.color}">
    <comboitem label="Red"/>
    <comboitem label="Blue"/>
   </combobox>
  </listcell>
  <listcell>
   <checkbox checked="@{person.married}" label="Are you married?"/>
  </listcell>
 </listitem>
</listbox>

MVC bez limitów

Jak już wspomniałem, przedstawiony powyżej przykład to realizacja dobrze znanego wszystkim programistom wzorca MVC (Model-View-Controller). Dzięki jego zastosowaniu kontroler odwołuje się tylko do modelu, a stan modelu odzwierciedlany jest po stronie widoku. Zauważmy, że widok może odzwierciedlać różnego rodzaju informacje biznesowe, nie tylko dane przeznaczone do wyświetlenia w tabeli, liście czy drzewie. Na przykład może to być informacja o uprawnieniach zalogowanego użytkownika. W zależności czy użytkownik posiada określone uprawnienia czy nie, stan aktywności poszczególnych kontrolek (np. przycisków akcji) może być inny. Co więcej na stan aktywności niektórych kontrolek może wpływać więcej niż jedna informacja.

Jak zrealizować zatem taką funkcjonalność nie łamiąc zasad MVC czyli nie manipulując właściwościami komponentów GUI z poziomu kontrolera? Jak się okazuje, technologia data binding dostępna w ZK w zupełności wystarcza do realizacji tego typu wymagań.

Załóżmy zatem, że wymaganiem jest aby przycisk Delete znajdujący się pod listą był aktywny tylko jeśli użytkownik posiada odpowiednie uprawnienia oraz został wybrany element na liście. W modelu przechowywać będziemy obiekt klasy Person, który reprezentuje aktualnie wybraną z listy osobę oraz obiekt klasy AccessMode reprezentujący tryb dostępu do danych (VIEW / EDIT) dla bieżącej strony dla aktualnie zalogowanego użytkownika.

Dane modelu będziemy przechowywać w kontrolerze (alternatywnie moglibyśmy umieścić je w jakiejś oddzielnej klasie modelu, do której nasz widok miałby dostęp). Mamy zatem następujące pola w kontrolerze:

private Person selected;
private AccessMode accessMode;

Tworzymy, metodę która zwróci nam informację o tym czy akcja Delete jest dostępna dla zalogowanego użytkownika:

public boolean isDeleteDisabled() { 
  return selected == null || accessMode == AccessMode.VIEW;
}

W następujący sposób tworzymy przycisk Delete, którego stan (enabled/disabled) chcemy powiązać z danymi znajdującymi się w modelu:

<button disabled="@{controller.deleteDisabled, load-after='listBox.onSelect'}" label="Delete"/>

Atrybutem load-after specyfikujemy kiedy komponent powinien odświeżyć swój stan. W naszym przypadku odświeżenie musi nastąpić po każdorazowej zmianie selekcji na komponencie listy.
Zwracam uwagę, iż atrybut load-after jest konieczny gdyż, ani model ani kontroler nie informują widoku o zmianie danych. Jest to wygodne rozwiązanie, widok aktualizuje się automatycznie w momencie wystąpienia określonego zdarzenia (Więcej o zdarzeniach w ZK napisałem w artykule ZK - tworzenie aplikacji sterowanej zdarzeniami).

Podsumowanie

Chciałbyś napisać aplikację internetową z użyciem Ajax-a i nie wiesz jak się za to zabrać? Dotychczas tworzyłeś aplikacje desktopowe i nie chcesz uczyć się wszystkiego od początku?. Framework ZK będzie dla Ciebie idealnym rozwiązaniem. Tak reklamuje się ZK i jak pokazałem w powyższym artykule, nie ma w tym wiele przesady.

http://pkaczor.blogspot.com/2010/10/zk-ajax-dla-kazdego.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.

ZK - tworzenie aplikacji sterowanej zdarzeniami

2010-10-28T00:00:00-07:00

Większość frameworków/bibliotek odpowiedzialnych za obsługę interfejsu użytkownika definiuje zdarzenia i dostarcza szereg mechanizmów służących do przechwytywania i przetwarzania zdarzeń. Komponenty GUI oferowane przez te biblioteki specyfikują jakie zdarzenia i kiedy są przez nie generowane oraz na jakie zdarzenia i w jakim celu nasłuchują. Zdarzenia to nie tylko akcje wykonane przez użytkownika takie jak kliknięcie myszką na przycisk, wybór elementu na liście czy naciśnięcie klawisza Enter w polu tekstowym. Komponenty używają bowiem zdarzeń również do komunikacji między sobą dzięki czemu powiązania między komponentami są luźne. Jest to jeden z ważnych czynników zwiększających elastyczność architektury systemu.

Dlaczego zatem nie wprowadzić zdarzeń do warstwy logiki biznesowej? Nie jest to nowa koncepcja, aczkolwiek rzadko spotykana w typowych aplikacjach biznesowych. Wynika to m.in. z braku odpowiedniego wsparcia ze strony frameworków aplikacyjnych. Z nadejściem JEE 6 sytuacja może się zmienić. Specyfikacja CDI definiuje prosty w użyciu model generowania i odbierania zdarzeń (podobny model od dawna oferuje Seam). Model ten jest uniwersalny i może mieć zastosowanie w różnych obszarach/warstwach aplikacji. W poniższym artykule zaprezentuję rozwiązanie jakie w tym zakresie oferuje framework ZK.

Przykładowa aplikacja

W typowej aplikacji biznesowej mamy zwykle do zaimplementowania obsługę grupy operacji określanej skrótem CRUD (tworzenie, zmiana, usuwanie) wykonywanych przez użytkownika na różnych obiektach biznesowych. W naszej przykładowej aplikacji zamodelujmy obsługę ról użytkowników. Mamy zatem ekran z listą ról oraz ekran edycji/tworzenia roli wyświetlany w oknie dialogowym. Rysunki poniżej.

Zdarzenie biznesowe

Zdarzenie w ZK definiowane jest jako obiekt klasy Event posiadający nazwę (name). Dodatkowo zdarzenie może mieć przypisany komponent docelowy (target) oraz dowolny obiekt z danymi (data).

Zdefiniujmy zatem zdarzenia biznesowe, które chcielibyśmy obsłużyć w naszej aplikacji:

onEdit - użytkownik wykonał akcję mającą na celu przejście do trybu edycji wybranego obiektu biznesowego
onAdd - użytkownik wykonał akcję mającą na celu przejście do trybu edycji nowego obiektu biznesowego
onDelete - użytkownik wykonał akcję mającą na celu usunięcie wybranego obiektu biznesowego
onSave - użytkownik wykonał akcję mającą na celu zapisanie zmian (modyfikacja bądź utworzenie obiektu biznesowego)

Przypisanie zdarzenia biznesowego do akcji użytkownika

W naszej aplikacji edycja następuje po kliknięciu na element listy, a tworzenie elementu po naciśnięciu przycisku znajdującego się pod listą. W obu przypadkach nastąpi wyświetlenie okna edycji (popup).

<window id="windowRoleList" apply="${roleListCtrl}">
  <listbox model="@{controller.listModel}" selectedItem="@{controller.selected}">
   <listitem self="@{each='role'}">
    <listcell>
      <a label="@{role.name}" forward="onClick=onEdit"/>
    </listcell>
    <listcell label="@{role.description}" />
   </listitem>
  </listbox>
  <toolbar>
   <button id="btnAdd" forward="onClick=onAdd"/>
   <button id="btnDelete" forward="onClick=onDelete"/>
  </toolbar>
 </window>

Zwróćmy uwagę na atrybuty forward zdefiniowane dla linku (element a w wierszu listy) i przycisku pod listą (element button).
W atrybucie forward podajemy nazwę zdarzenia jakie zostanie propagowane w górę drzewa komponentów. Propagowanie odbywa się poprzez utworzenie nowego zdarzenia (o nazwie podanej po znaku równości) zawierającego zdarzenie źródłowe (o nazwie podanej przed znakiem równości). W naszym przypadku zdarzeniem źródłowym jest zdarzenie systemowe onClick (kliknięcie na przycisk/link). W przypadku nie podania zdarzenia źródłowego, przyjmowane jest domyślne, różne w zależności od komponentu dla jakiego specyfikujemy atrybut forward. W przypadku linka i przycisku jest to zdarzenie onClick. Zatem oba zapisy są tożsame:

<button forward="onClick=onAdd"/>
<button forward="onAdd"/>

Zdefiniowaliśmy zatem, po jakiej akcji użytkownika nastąpi określone zdarzenie biznesowe. Odseparowaliśmy tym samym logikę interfejsu użytkownika od logiki biznesowej. Gdybyśmy dla innego obiektu biznesowego edycję chcieli przeprowadzić nie w osobnym oknie, lecz w tym samym, w którym znajduje się lista wyboru, zdarzenie onEdit moglibyśmy zdefiniować jako następstwo wyboru elementu na liście:

<listbox model="@{controller.listModel}" selectedItem="@{controller.selected}" 
   forward="onSelect=onEdit"/>

W obu przypadkach logika obsługi zdarzenia onEdit będzie taka sama. Przyjrzyjmy się zatem jak obsłużyć zdarzenie w kodzie aplikacji.

Obsługa zdarzenia

Zdarzenie propagowane jest aż do komponentu okna (window) i następnie zostaje przekazane do kontrolera podpiętego pod to okno (kontroler definiujemy atrybutem apply). W naszym przypadku kontroler jest bean-em zarządzanym przez Springa o nazwie roleListCtrl (użycie Spring-a jest opcjonalne).

Kontroler musi zdefiniować metodę odpowiadającą nazwie zdarzenia:

public void onEdit(Event event);

Wiemy zatem, w jaki sposób nasze zdarzenie biznesowe może być utworzone i obsłużone w wyniku akcji podjętej przez użytkownika. Spyta ktoś, czym to rozwiązanie różni się od klasycznego podejścia używanego w innych frameworkach np. Seam, gdzie możemy analogicznie wywołać metodę w kontrolerze:

<button action="#{controller.onEdit()}"/>

Rozpatrzmy różnice między oboma podejściami z punktu widzenia interfejsu wywołania/obsługi komunikatu :

Seam: w metodzie możemy przekazywać dowolną ilość argumentów, dowolnego typu.

ZK: W zdarzeniu możemy przekazać jeden obiekt danych (możemy np. przekazać wybraną rolę: forward=onEdit(role)) . Typem danych jest zawsze Object. Porównując zatem z wywołaniem metody, mamy ograniczoną ilość argumentów i konieczność rzutowania typu po stronie kontrolera. Zwykle jednak nie ma konieczności przekazywania większej liczby argumentów (w naszym przykładzie nie musimy przekazywać roli w zdarzeniu, gdyż framework potrafi wstrzyknąć do kontrolera wybraną rolę automatycznie). Podkreślić należy, że oba problemy wynikają z ograniczeń jakie niesie ze sobą propagowanie zdarzeń przy przy pomocy atrybutu forward. Nie istnieje tutaj możliwość stworzenia własnej klasy zdarzenia. Gdy wysyłamy zdarzenie w kodzie aplikacji (przykład później),problemy powyższe nie istnieją.

Przejdźmy w końcu do przykładów, gdzie zdarzenia zaczynają pokazywać swoją moc:)

Zdarzenia w akcji

W przypadku gdy wyświetlamy kilka okien na stronie możemy używać zdarzeń do komunikacji między oknami sterując w ten sposób logiką aplikacji.

Dodajmy na naszej stronie z listą ról nowy panel z listą użytkowników. Lista ról niech wyświetla tylko role dla wybranego użytkownika (z możliwością ich edycji). Obie listy umieszczamy w oddzielnych oknach (komponentach window) dzięki czemu obie listy możemy obsługiwać oddzielnymi kontrolerami (w obu oknach chcemy obsłużyć logikę CRUD). Odświeżenie listy ról po wybraniu użytkownika obsługujemy następująco:

//Kontroler użytkowników

public void onSelect(Event event) {
    //inform role list window on selection change
    Component roleListWindow = self.getFellow("windowRoleList");
    Events.postEvent(new Event("onUserSelected", roleListWindow, getSelected()));
}

//Kontroler ról

public void onUserSelected(Event event) {
    selectedUser = (User)event.getData();
    refreshList();
}

Dzięki temu, że zdefiniowaliśmy zdarzenie onUserSelected, możemy zarejestrować słuchaczy obserwujących to zdarzenia w celu zaimplementowania dodatkowej logiki. Jako przykład wykorzystam wbudowany w ZK mechanizm sterowania bindowaniem danych. Co to jest bindowanie? Jest to możliwość bezpośredniego połączenia warstwy modelu (danych) z kontrolkami wyświetlającymi/modyfikującymi te dane. W ZK bindowanie może obejmować dowolne właściwości kontrolek np. stan kontrolki (czy kontrolka jest aktywna czy nie (enabled/disabled)). Dodajmy zatem wymaganie w naszej aplikacji aby usunięcie roli było możliwe tylko dla użytkownika nowo utworzonego (dla którego pole registered = false). Musimy zatem przy zmianie selekcji użytkownika deaktywować bądź aktywować przycisk Delete pod listą ról. Korzystając z możliwości mechanizmu bindowania ZK konfigurujemy właściwość disabled dla przycisku Delete:

<button id="btnDelete" forward="onDelete"
        disabled="@{controller.selectedUser.registered, load-after='windowRoleList.onUserSelected'}"/>

Użycie @ w wyrażeniu oznacza zastosowanie bindingu. W naszym przypadku odczytujemy pole registered z obiektu użytkownika przekazanego uprzednio do kontrolera (patrz kod wyżej). Za pomocą parametru load-after, wskazujemy zdarzenie, po nastąpieniu którego nastąpi odświeżenie przycisku (odczytanie danych z modelu). Framework automatycznie zarejestruje odpowiedniego listenera w komponencie naszego okna nasłuchującego na zdarzenie onUserSelected.

Zauważmy co zyskujemy. Kod obsługujący zdarzenie onUserSelected jest czysty. Modyfikujemy w nim tylko stan modelu, czyli ustawiamy zmienną selectedUser i odświeżamy listę ról (model). Zarówno przy odświeżaniu listy ról jak i odświeżaniu przycisku na stronie zostanie odczytane pole selectedUser. Kontroler nie musi wiedzieć kiedy odświeżyć przycisk, nie musi nawet wiedzieć o jego istnieniu.

Zdarzenia globalne

Przedstawione dotychczas zdarzenia były wysyłane do konkretnego komponentu. Nie zawsze jest to pożądane. Jedną z podstawowych cech architektur sterowanych zdarzeniami jest możliwość niezależnego wysyłania i odbierania zdarzeń. Emitent zdarzenia nie musi znać odbiorców. Odbiorca nie musi wiedzieć skąd zdarzenie pochodzi. Jak tę funkcjonalność zrealizować w ZK pokaże znowu na konkretnym przykładzie. Dodajmy na górze naszej strony panel zawierający nazwę zalogowanego użytkownika. Pojawia się kwestia odświeżenia zawartości panelu w momencie modyfikacji nazwy aktualnie zalogowanego użytkownika. W kontrolerze obsługującym okno edycji użytkownika implementujemy obsługę zdarzenia onSave.

public void onSave(Event event) {
    //save user
    ....
    //inform potential listeners
    EventQueue lookup = EventQueues.lookup("QUEUE_GLOBAL", true);
    lookup.publish(new UserChangedEvent("onUserChanged", user));
}

Wysyłamy zatem zdarzenie onUserChanged bez adresata do kolejki o zdefiniowanej przez nas nazwie QUEUE_GLOBAL. Zauważmy, że tym razem zdefiniowaliśmy własną klasę zdarzenia (UserChangedEvent), w której przekazujemy obiekt użytkownika. Standardowo, rejestracja w kontrolerze słuchacza zdarzeń z tej kolejki wygląda w następujący sposób:

//kontroler nagłówka
 public void onCreate(Event event) {
  EventQueues.lookup("QUEUE_GLOBAL", EventQueues.DESKTOP, true)
   .subscribe(new EventListener() {
    @Override
    public void onEvent(Event event) throws Exception {
     //process event 
    }
   });
 }

Rejestrację można uprościć i jednocześnie ułatwić kontrolerowi obsługę zdarzenia tworząc klasę pośrednicząca w odbieraniu i przekazywaniu zdarzeń do wybranego przez nas komponentu (nazwijmy ją EventsManager):

public class EventsManager {
 public static void subscribe(String queue, final Component component) {
  EventQueues.lookup(queue, EventQueues.DESKTOP, true)
   .subscribe(new EventListener() {
    @Override
    public void onEvent(Event event) throws Exception {
     Events.sendEvent(component, event);
    }
   });
 }
}

Teraz w kontrolerze nagłówka możemy w sposób standardowy zaimplementować obsługę zdarzenia onUserChanged.

// kontroler nagłówka

public void onCreate(Event event) {
  //register self (window component) as listener of events from QUEUE_GLOBAL
  EventsManager.subscribe("QUEUE_GLOBAL", self);
}

public void onUserChanged(UserChangedEvent event) {
  if (event.getUser().eqauls(getUserWorkspace().getLoggedInUser()) {
   //refresh component displaying user name
   ...   
  }
}

Używając zdarzeń globalnych uwalniamy emitenta zdarzenia od konieczności znajdowania komponentu docelowego. Jednocześnie uwalniamy odbiorcę od rejestracji nasłuchiwania w konkretnym komponencie. Wystarczy, że obie strony uzgodnią kanał (kolejkę) komunikacji. Zdarzenia globalne domyślnie wysyłane i odbierane są w kontekście strony przeglądarki (desktop-level).
ZK pozwala również funkcjonować zdarzeniom w kontekście całej aplikacji. Dzięki temu strona może zostać odświeżona pomimo braku akcji ze strony zalogowanego użytkownika (np. na skutek operacji wykonanej przez scheduler-a uruchomionego na serwerze). Umożliwia to technologia Push Server, oferowana wewnątrz ZK.

http://pkaczor.blogspot.com/2010/10/zk-tworzenie-aplikacji-sterowanej.html

Autor: Paweł Kaczor

Programista, pasjonat, konsultant IT. Interesuje się nowoczesnymi framework-ami webowymi takimi jak: Seam, ZK. Obecnie w wolnym czasie poznaje język Scala.