Book Review: Building a RESTful Web Service with Spring

I am happy to announce the publishing of this book. I have had the pleasure of working with technical team that produced it, and I can say for sure it will be a good acquisition for those who want to learn and improve the expertise in designing and implement RESTful services in high professional business scenarios.

This book is a very practical guide to create your first RESTFul web service, or even to improve your current web product. It covers major topics regarding architectural design, testing and useful performance aspects for running your service in a high scalable manner.

There are also good code samples to demonstrate the chapter topics, all based in the Spring Framework, a great development platform to rapid java application development.

Book information

Author: Ludovic Dewailly

Pages: 115

You can get it at a good price for Kindle, or buy it directly from packtpub web site here.

_________________________________________________________________

Versão em português (pt-BR version)

Estou feliz em anunciar a publicação deste livro. Tive o prazer de trabalhar na equipe técnica que o produziu e posso dizer com certeza que será uma boa aquisição para aqueles que querem aprender e aperfeiçoar sua habilidade em projetar e implementar serviços RESTful em cenários de negócio altamente profissionais.

Esse livro é um guia prático para criar o seu primeiro RESTful web service, ou até melhorar seu projeto existente. Ele aborda os principais tópicos relacionados a arquitetura, testes e aspectos de performance para executar seu serviço de uma maneira extremamente escalável.

Há também bons exemplos de código para demonstrar os capítulos, tudo baseado no Spring Framework, uma ótima plataforma de desenvolvimento para  rápida implementação de aplicações java.

Hexagonal Architecture – Java Starter Project

I have shared the sample code for the  Hexagonal Architecture presentation. You can find the source code  at: github.com/fabricioepa/lab-hexagon-java But I should remeber you these patterns are not exclusively related to the Java technologies and frameworks.

My professional experience using this technique

It was very simple to create a decoupled REST adapter from the core application, it should be simple to create another kind of adapter too. However, if the application domain is quite BIG or there are many ports and adapters, you will have some overhead to maintain different domains translated from the original application core domain. The PORT interface should also have a stable API definition, you should design it to support evolution without easily break compatibility with the adapters implementations for that PORT. As inital strategy to achieve that design, the project has domain events to encapsulate all input and output data for the service, enabling the application to evolute without directly break the adapter code of the API.

core/api/src/main/java/com/ticketapp/core/api/TicketService.java

/**
 * Ticket Service - Use Case API
 */
public interface TicketService {

    TicketsReadEvent list(ReadTicketsEvent event);

    TicketCreatedEvent create(CreateTicketEvent ticket);

    TicketUpdatedEvent update(UpdateTicketEvent ticket);

    TicketDeletedEvent delete(DeleteTicketEvent ticket);
}

This is one reason for this pattern has often been applied to microservices architecture, because it works nice for multiple system integrations and also for small/medium sized application domains. If the application domain starts to grow up, may be it is the time to think about design a new hexagon to it.

Feel free to bring up your ideas 😉

Hexagonal architecture

Objective

“Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.” (Alistair Cockburn)

Summary

This approach aims to simplify the application integration and it is a powerful strategy to rapidly compose new services. The pattern has been often applied with the microservice architecture and may be the future of the SOA, bypassing the meddiation of the Enterprise Service Bus (ESB), enabling high performance and scalability.

RESTful Java Web Applications with Spring Boot + CQRS Pattern

I am sharing a sample project to demonstrate some cool features of the Spring Boot with Spring framework 4.0, the project is part of the workshop series at the embeddedlab.org #2015

The application is based on the CQRS pattern (Command Query Responsibility Segregation), introduced by Greg Young, decoupling the models for the Read/Write operations.

The pattern is better described by Martin Fowler in his blog (http://martinfowler.com/bliki/CQRS.html)

“The other main benefit is in handling high performance applications. CQRS allows you to separate the load from reads and writes allowing you to scale each independently…”

It means you can create lightweight data structures to read thousands of data and also have complex object structures to read detailed information for the same entity in the domain.

You can find the source code  at:

github.com/fabricioepa/lab-springboot-rest-sample

Feel free to bring up your ideas and comments

Hope you enjoy it. 😉

JBean File Storage

Após um bomtempo sem publicar devido a minha dedicação ao projeto “Easy Accept Web” (mas isso fica para outro post), anuncio um novo componente para auxílio a manipulação e associação de caminhos de arquivos/diretórios com POJOS. Muito útil quando sua aplicação trabalha em conjunto com framework ORM (Hibernate like), onde se deseja por exemplo associar uma entidade com um determinado diretório de arquivos (para upload/download por exemplo), seu nome por enquanto é :

JBean File Storage

O componente ainda apesar de implementado ainda não está disponibilizado publicamente pois ainda necessita de revisão, documentação e algumas possíveis melhorias embora esta versão esteja presente em 2 projetos já em produção.

A idéia chave foi associar um caminho a um tipo java, eu mentiria se dissesse que a idéia foi completamente minha pois me baseei numa solução proposta por Luciano Logrado ao trabalharmos juntos em um outro projeto, digamos que eu incrementei a idéia para suportar polimorfismo e com isto será possível:

  • Associar um caminho a uma tipo (classe ou interface) e seus subtipos também estarão associados
  • Usar uma Expression Language (semelhante a do JSP 2.0) mínima para usar caminhos dinâmicos
  • Herdar um caminho dum outro POJO
  • Manter na hierarquia de diretórios a hierarquia nas associações dos POJOS

Estes dois últimos são importantes caso por exemplo existam dois POJO’s com relacionamento de pai/filho e ao excluir o pai os filhos devem ser excluídos:

Cliente ->* Conta

Desta forma o caminho de arquivos do cliente poderia ser:

$/Cliente_99

/Conta_33

MeuExtrato1.txt

/Conta_34

Extrato2008.txt

Com uma operação de exclusão do diretório do cliente haverá propagação no sistema de arquivo para os subdiretórios, ou seja, as contas. Além de manter a organização dos arquivos numa hierarquia de pastas de fácil entendimento visual e manipulação.

Veja detalhes do uso:

Read More

BugBuster 1.0 – Hibernate Exception: Illegally attempted to associate a proxy with two open Sessions

O referido erro também ocorre com mesagem semelhante:

Illegal attempt to associate a collection with two open sessions

Causa:

O erro é provocado quando um hiberObject associado a uma sessão tenta ser alterado por outra sessão do hibernate.

Solução:

Esqueça os métodos session.get/load/update você pode conseguir o mesmo efeito com session.refresh/merge.

Contexto do Problema:

Isso acontece devido a associação de um objeto gerenciado pelo hibernate (hiberOjbect) com a sessão que o carrega. Tecnicamente se um objeto foi carregado por uma sessão, até que o objeto seja desconectado (passando para o estado Detached) ele permanece associado a ela. O que pode ser feito invocando os métodos:

//Apenas se os relacionamentos do hiberOject
//que possuem cascade="evict" eles serão também desconectados
session.evict(hiberObject);
session.clear();
session.close();
 

Se outra sessão tentar alterá-lo sem ele estar destacado da última sessão, o erro será lançado.

Problemas Típicos:

1. 0 Quando se deseja usar um objeto em outra sessão sem fechar a primeira use o evict, lembrando que se os relacionamentos não possuirem cascade=”evict” o efeito do método não servirá para eles e provavelmente o mesmo erro ocorrerá para o “proxy” dos relcionamentos (que podem ser coleções causando Illegal attempt to associate a collection with two open sessions) .

2.0 Em Aplicações WEB Java tipicamente carregamos um hiberObject e o setamos em alguma variável do contexto web (request, session, sevletContext), após algum uso pela camada de apresentação fazemos outra chamada a camada do hibernate usando esse mesmo hiberObject onde ocorre falha com o dito erro. Neste caso temos dois pontos:

  • Se a sessão que o carregou anterior ainda estava aberta você recai no erro 1.0
  • Caso a velha sessão já tenha morrido, o seu hiberObject não está mais conectado a mesma, porém os seus relacionamentos ainda podem ter algum “proxy” para a velha sessão. Nesse caso é mais simples usar um dos metódos:

//Caso queira reconectar e recarregar
//no seu objeto os dados do banco
session.refresh(detachedHiberObject);

//Caso queira reconectar o objeto fazer um update no banco
//de dados com as novas informações setadas no objeto
connectedHiberObject = session.merge(detachedHiberObject);

 

O merge/refresh tem funções diferentes, mas ambos reconectam o objeto a uma sessão, seja a mesma ou não, sem provocar erro.

Java Tips 1.0: (2 em 1) Carregue jars dinamicamente – Acesse métodos protegidos

Você já se perguntou como algumas IDE’s configuram o classpath da sua aplicação dinamicamente em tempo de execução?

Aqui vai uma solução técnica alternativa (that means GDD – Gambiarra Driven Development :P).

A classe java.net.URLClassLoader é o classloader default do sistema para carregar o jars do classpath quando o aplicativo java é iniciado.
Uma maneira de adicionar jars extras seria invocando no classloder o método addURL(URL url), o que faz o jar localizado por está URL ser carregado na JVM em execuçao. O problema é que este método é protegido (protected) e portanto, a menos que você extenda o URLClassLoader, sobreescreva o método mudando a visibilidade para público e configure seu classloder como default do sistema você não poderá invocá-lo na instância do classloader.
Mas como nem tudo é impossível na computação, você pode contornar o problema usando reflexão e acessando o método protegido. Para isso basta recuperar o método “addURL” declarado e invocar setAccessible(true).

A classe abaixo mostra como você mata os dois coelhos com uma única cajadada:


public class ClassPathHacker {

private static final Class[] parameters = new Class[]{URL.class};

public static void addFile(String s) throws IOException {
 File f = new File(s);
 addFile(f);
}//end method

public static void addFile(File f) throws IOException {
 addURL(f.toURL());
}//end method

public static void addURL(URL u) throws IOException {

	URLClassLoader sysloader = (URLClassLoader)ClassLoader.getSystemClassLoader();
 Class sysclass = URLClassLoader.class;

	try {
 	Method method = sysclass.getDeclaredMethod("addURL",parameters);
 	method.setAccessible(true);
 	method.invoke(sysloader,new Object[]{ u });
 } catch (Throwable t) {
 	t.printStackTrace();
 	throw new IOException("Error, could not add URL to system classloader");
 }//end try catch

}//end method

}//end class

Baseado no Fórum:

http://forum.java.sun.com/thread.jsp?forum=32&thread=300557&tstart=0&trange=15

Interceptando a execução do SQL da sua aplicação

Proxy4jdbc3 – The Proxy for JDBC 3

É um componente de software desenvolvido para interceptar o SQL executado por um aplicativo Java através das chamadas sobre a JDBC. Uma solução rápida e simples para quem deseja depurar, fazer logging ou perfilar a execução do SQL sem ter que modificar a arquitetura da aplicação.

Para usá-lo primeiro são necessários apenas 4 passos:

  1. É necessário saber qual o componente provedor das conexões com os dados da sua aplicação, exemplo: Driver Manager, DataSource, algum Componente de Pooling, etc…,
  2. Conhecido o provedor, então deve se escolher o componente correspondente de Proxy. Obs.: Você também pode estender ou criar seu componente customizado.
  3. Implementar o Proxy criando a solução vendor-especifc, i.e, especifica do seu SGBD. No pacote proxy4jdbc3.solutions.* você encontrará soluções-exemplo.
  4. Substitua a referência ao provedor de conexão pela referência ao Proxy.


O componente foi desenvolvido sobre a JDBC 3, e está ainda em fase de teste (beta).

Maiores informações em: http://proxy4jdbc3.sourceforge.net/