O que é SOA, afinal?

Um assunto um tanto delicado, ainda não debatido aqui no blog, é a respeito de SOA - Service Oriented Architecture. Tanto DDD quanto SOA são assuntos relativamente novos. Porém, enquanto o primeiro está bem definido e estabelecido na comunidade de desenvolvimento de software, o segundo ainda carece de alguns padrões que unifiquem as diferentes visões que existem sobre a técnica. Este post é o início da minha colaboração (meus 2 cents).

Definição

Definir SOA é complicado. A maioria das definições é baseada na ideia de sistemas compostos por serviços independentes. Entretanto, o que exatamente constitui um serviço não está claro. O que não resta dúvida é o fato de SOA ser uma forma arquitetural de se desenvolver software, forma guiada pela reutilização e compartilhamento entre aplicações e componentes. Nas palavras do mestre Udi Dahan:

Specifically, SOA deals with systems or applications that are, or can be, distributed. The acknowledgment that distribution is a primary architectural issue is one of the underlying currents of SOA.

O software que precisa rodar em um ambiente distribuído tem de ser projetado de forma diferenciada. As layers e tiers no mundo SOA são unificadas em "serviços", que são ao mesmo tempo unidades de design e de deployment. Enquanto que numa arquitetura tradicional  não há restrição em como essas camadas irão se comunicar, em SOA os serviços devem se comunicar de acordo com padrões de mensagens definidos por um schema (ou contrato).

O que é um Serviço?

Muito da literatura existente hoje foca em descrever propriedades (e princípios) dos serviços em vez de definir o que um serviço é de fato. Na essência, sabemos que a classe que implementa determinado serviço deve ser desacoplada dos clientes que evetivamente a consomem. Isso é bem diferente dos ambientes Java RMI, COM e .NET remoting, onde o cliente precisa explicitamente referenciar tipos específicos de plataforma. 

Vejamos então os princípios fundamentais de um serviço:

- Serviços são autônomos: autonomia significa a capacidade de se autogovernar, um serviço autônomo é aquele que independe de um elemento externo para executar sua lógica.

- Serviços têm fronteiras bem definidas: essa definição está lado a lado com o princípio da autonomia; torna claro onde um serviço termina e outro começa.

- Serviços abstraem a lógica: serviços devem ser tratados como uma caixa preta, assim como componentes de um sistema. Assim sendo, a programação neles inclusa pode ser substituída a qualquer momento, sem afetar aqueles que o consomem.

- Serviços expõem schema e contratos, não classes ou tipos: contratos são documentos textuais que descrevem o que o serviço faz, os padrões WSDL (Web Service Description Language), UDDI (Universal Description Discovery and Integration) e SOAP (Simple Object AccessProtocol) são muito utilizados no dia a dia.

- Serviços são reutilizáveis: um serviço reutilizável é aquele que não carrega particularidades técnicas de uma implementação ou regras de negócio específicas e é genérico o suficiente para atender outros projetos. 

OO e SOA

Segundo Udi Dahan, apesar de muitos terem previsto que SOA seria a próxima geração do desenvolvimento de aplicações - com a consequente substituição do padrão OO atual - nada  significativo realmente aconteceu. Na verdade, SOA e OO trabalham em diferentes (e complementares) níveis. OO lida com design e código de uma única deployment unit enquanto SOA lida com múltiplas deployment units. Dahan nos explica:

SOA does not suggest new or alternate ways of designing or coding the internal logic of a given application or service. There is no reason SOA and OO should not be  cooperative technologies.

Princípios fundamentais de OO como separation of concerns e dependency inversion estão presentes na construção de aplicações service oriented, tanto na arquitetura externa como na construção interna de seus serviços. SOA é complementado por OO; não é a evolução do OO. No entanto, podemos considerar SOA como a evolução da arquitetura distribuída de componentes.

Conclusão

Há vários anos que SOA é assunto nas rodas de TI. Apesar de haver muito barulho em torno do tema, não há dúvida de que é um conceito interessante e uma técnica atraente para construção de componentes (serviços) reutilizáveis. SOA e OO não são incompatíveis. Em muitos níveis OO fornece insights válidos para construção de serviços robustos e independentes de plataforma. Para os que se interessaram pelo tema, sugiro a leitura e pesquisa para atualização da visão atual da técnica, muita coisa têm mudado a respeito do tema nos últimos anos. Voltarei posteriormente com o assunto aqui no blog.

DDD e EJB 3.0

DDD é uma técnica poderosa para se construir software focado no negócio da organização e apoiado na linguagem corrente dos que irão utilizar o sistema. Dessa forma, o aplicativo é construído de "dentro para fora", permitindo que regras de negócio sejam implementadas (e testadas) bem antes da construção das outras camadas e partes importantes do sistema como telas, controles e bancos de dados.

Em algum momento, teremos que implementar funcionalidades para outras camadas  e alguns serviços essenciais como controle de transações, object pool, injeção de dependência, persistência dos objetos de domínio, etc. Nesse post vou apresentar uma ideia geral de como poderíamos realizar essas tarefas de modo bem simples usando EJB 3.0.

Antes de tudo uma observação: se você (como eu) odeia as complexidades e complicações do EJB 2.0 e torceu o nariz no instante que leu o título desse post, saiba que a versão 3.0 é completamente diferente da anterior. Os session beans e entidades JPA são agora objetos leves e que permitem (entre outras coisas) que sejam testados fora do container que os gerencia. Se você gosta da ideia de trabalhar segundo as premissas de Eric Evans e curte criar POJOs para resolver seus problemas então EJB 3.0 é a ferramenta perfeita para suas necessidades.

Primeiramente, vamos criar uma interface genérica para nossos repositórios:

@Local
public interface Repositorio<T> {
   
    List<T> buscarTodos();

    T buscarPorID(int id);

    void add(T object); 

    void remove(T object);

    void update(T object);
}

Não fosse pela anotação @Local poderíamos dizer que essa seria uma interface comum escrita em Java. Aquela anotação diz que essa interface permitirá acesso a uma referência de um session bean que reside na mesma máquina que o container web. Caso precisássemos de acesso remoto, bastaria anotar a interface com @Remote para termos acesso a um enterprise bean residente em outro servidor.

Vamos agora implementar a interface Repositorio em uma classe RepositorioDeClientes:

@Stateless
public class RepositorioDeClientes implements Repositorio<Cliente> {

    @PersistenceContext()
    private EntityManager entityManager;

    public List<Cliente> buscarTodos() {

        Query query = entityManager.createQuery("select c from Cliente c");
        return query.getResultList();

    }

    public void remove(Cliente object) {

            entityManager.remove(entityManager.merge(object));
    }

    public Cliente buscarPorID(int id) {

        Cliente cliente = entityManager.find(Cliente.class, id);
        return cliente;
    }

    public void add(Cliente object) {

            entityManager.persist(object);
    }

    public void update(Cliente object) {

            entityManager.merge(object);
    }
   
}

RepositorioDeClientes é uma classe POJO normal, transformada em um poderoso session bean sem estado através da anotação @Stateless. O container gerencia um pool de objetos RepositorioDeClientes para servir aos usuários de seus serviços - usuários dessa e de outras aplicações. Além disso, usamos o recurso de dependency injection com a anotação @PersistenceContext, que serve para injetar um objeto EntityManager, elemento JPA responsável em gerenciar o provider OR/M usado na camada de infra-estrutura.

JPA, através da interface EntityManager, gerencia as entidades marcadas com a anotação @Entity fornecendo serviços de  persistência para os objetos. Funciona como um "guarda-chuva" para os diversos providers de mapeamento objeto relacional existentes no mercado como TopLink e Hibernate (para o exemplo o provider utilizado foi o Hibernate).

Anotando a entidade cliente:

@Entity
@Table(name="CLIENTES")
public class Cliente implements Serializable {

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    @Column(name="CLIENTE_ID", nullable=false)
    protected int clienteID;

    @Column(name="NOME", nullable=false)
    protected String nome = "";

    @Column(name="LOGIN", nullable=false)
    protected String login = "";

    @Column(name="EMAIL", nullable=true)
    protected String email = "";

    @Column(name="SENHA", nullable=false)
    protected String senha = "";

    @Column(name="TELEFONE", nullable=true)
    protected String telefone = "";

    @Embedded
    protected Endereco endereco;

    public Cliente() {
        this.endereco = new Endereco();
    }

    //getters, setters e outros métodos 

}

Várias anotações (como @Table, @ID e @Column) dão importantes informações ao JPA de como deve ser feito o mapeamento objeto-relacional de uma maneira fácil e segura. O mais interessante é que as anotações são ignoradas pela JVM fora do contexto do container EJB e do controlador de entidades JPA. Em outras palavras, podemos testar tudo sem a necessidade de um aparato complicado que certamente prejudicaria a testabilidade dos componentes (conceito caro para quem trabalha com TDD).

Com tudo isso pronto, poderíamos ter um servlet controlador com um código parecido com esse:

public class GerenciarClienteServlet extends HttpServlet {

    @EJB
    Repositorio repositorio;

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
    

        Cliente cliente = new Cliente();

        RequestDispatcher rd = null;

        try {
  
            //validações excluídas para melhorar a legibilidade
            cliente.setNome(request.getParameter("nome"));
            cliente.setLogin(request.getParameter("login"));

            //dados de endereco
            cliente.getEndereco().setRua(request.getParameter("rua"));
            cliente.getEndereco().setBairro(request.getParameter("bairro"));
            cliente.getEndereco().setCidade(request.getParameter("cidade"));
            cliente.getEndereco().setEstado(request.getParameter("estado"));

            cliente.setSenha(request.getParameter("senha"));
            cliente.setTelefone(request.getParameter("fone"));
            cliente.setEmail(request.getParameter("email"));

            repositorio.add(cliente);

            request.setAttribute("cliente", cliente);
            request.setAttribute("mensagem", "Cliente cadastrado com sucesso!");

            rd = request.getRequestDispatcher("/cadastroCliente.jsp");
            rd.forward(request, response);

        } catch (Exception e) {
           //gero log, direciono para página de erro, etc
        }

    }

A anotação @EJB injeta uma instância de RepositorioDeClientes e passa a controlar o seu ciclo de vida, facilitando muito o trabalho do desenvolvedor. Quem fica responsável pela criação do objeto é o  próprio container, que também se encarrega de sua destruição. O container irá criar um pool de objetos para otimizar o desempenho da aplicação. É importante observar que um servlet compartilha a mesma instância com vários clientes e por isso não devemos injetar um session bean @Stateful pois esse manterá o estado do objeto entre todas as requisições. Como nosso EJB do exemplo é  anotado com @Stateless podemos injetá-lo sem problemas.

Concluindo, nessa breve introdução, vimos como é viável trabalhar com um design limpo (orientado ao domínio e utilizando POJOs) e utilizar os recursos oferecidos pelo EJB de maneira fácil e descomplicada. A maior parte da "magia negra" do EJB é devida aos recursos oferecidos pelas anotações Java. Transformar uma classe em um poderoso enterprise bean apenas usando uma anotação @Stateless é simplesmente bom demais para ser ignorado.

Para saber mais: 

http://www.amazon.com/EJB-3-Action-Debu-Panda/dp/1933988347
http://www.amazon.com/Enterprise-JavaBeans-3-1-Andrew-Rubinger/dp/0596158025 (previsão 09/2010)

OO, eu?

Mesmo uma linguagem orientada a objetos, como Java ou C#, pode ser utilizada, de forma consciente ou não, para criação de programas com base no paradigma estruturado. Nesse paradigma é grande a quantidade de estruturas de controle (como IF, IF-ELSE e SWITCH) e repetição (FOR, DO/WHILE). A pergunta que fica é: programas escritos utilizando orientação a objetos não precisam de tais estruturas? Como ficariam essas situações no código? Vejamos...

POO é sobre design. É o design da aplicação que determina se ela está aderente à metodologia estruturada ou à metodologia de objetos.

É claro que mesmo nas aplicações OO sempre haverá a necessidade de seleções e decisões. A diferença está na forma e na quantidade que tais elementos aparecem. Utilizando polimorfismo, um método que receba um parâmetro do super-tipo, por exemplo, não precisará de teste condicional, pois a implementação concreta será decidida somente no momento da passagem do objeto.

Observe (em C#):

    //uma Classe qualquer
    public void CalcularSalarioFuncionario(Funcionario funcionario)
    {
        //Gerente ou Vendedor? Só na hora será decidido.
        decimal valor = funcionario.CalcularSalario();

        //continuacao do método
    }

Um bom design OO diminui a necessidade de estruturas condicionais e de controle, porém não a elimina por completo. O fato é que isso (a eliminação) não é necessário para se obter um bom design, que seja robusto, de fácil manutenção e flexível.

Ex: Repositorio (em Java)

    //Classe RepositorioDePedidos
    public List buscarPedidosPorClienteID(int clienteID) {

     List pedidosDoCliente = new ArrayList();

     if (pedidos !=null) {

           for (Pedido pedido : pedidos) {   
                
                 Cliente cliente = pedido.getCliente();            
     
                 //aqui seria melhor usar o método equals() sobrescrito
                 if (cliente.getClienteID == clienteID) {
                      pedidosDoCliente.add(pedido);
                 }
           }
      }

      return pedidosDoCliente;
    }     


Repare que o método buscarPedidosPorClienteID tem elementos de decisão, seleção e controle. Tal situação ocorre a todo momento dentro dos repositórios.


E como poderia ser um cliente desse repositório?


    //uma Classe de controle qualquer
    public void gerarListaDePedidos(int clienteID)
    {
        RepositorioDePedidos repositorio = new RepositorioDePedidos();

        List pedidos = repositorio.buscarPedidosPorClienteID(clienteID);

        //renderizo uma tela, gero um relatorio, etc
    }  


O consumidor da classe RepositorioDePedidos  dispõe de uma API útil para buscar pedidos de um determinado cliente, dado o seu ID. Ele não sabe como o método funciona (encapsulamento), sabe apenas que funciona. A classe é reutilizável (várias instâncias podem ser criadas), fortemente tipada (somente o tipo Pedido) e tem detalhes de implementação desconhecidos (classe concreta ArrayList).

Com essas características não temos dúvida que o código de exemplo é OO, mesmo com a presença de elementos fundamentais de programação.

Um bom design OO diminui a necessidade de estruturas condicionais e de controle. Patterns, polimorfismo e outras técnicas podem ser utilizadas para tornar o código melhor escrito.

Mais informações sobre sobre estruturas de controle em programas aqui.

Arquitetura para o DDD

Continuando a série sobre o Domain Driven Design iniciada aqui, vamos agora comentar sobre como arquitetar as camadas da aplicação de modo a utilizar um Domain Model rico como a "base" do desenvolvimento.

Antes de mais nada, convém salientar que essa não deve ser vista como a única arquitetura que existe e que irá atender a todos os sistemas e situações do mercado. Trata-se apenas da arquitetura mais adequada a um projeto que trabalhe sob as premissas do DDD.

As camadas são representadas como abaixo:

Explicação sobre as camadas:

É importante dizer que não considero a camada Application como mandatória; ela é criada apenas se realmente adicionar valor à aplicação. Como a camada Domain é bastante rica em funcionalidades, muitas vezes não é necessário implementar mais essa divisão.

A criação de um Domain Model  traz uma série de vantagens para aplicações de larga escala e/ou complexas. Como bem disse Martin Fowler em PoEAA: "se você utilizar DDD para um projeto, você provavelmente irá cogitar utilizar a mesma técnica para outros (mesmo para os pequenos)."

Um design focado na criação de um Domain Model tem melhor manutenção no longo prazo devido à clareza da relação entre o negócio e a implementação. Além disso, é uma importante ferramenta para evitar a duplicação de código. Também aumenta a testabilidade do sistema.

Ubiquitous Language

Sempre que encontro com meus amigos guitarristas é uma festa... O assunto principal, como não poderia deixar de ser, é sempre sobre guitarras e tudo que essas preciosidades podem fazer. Falamos sobre as pickups que nossos ídolos utilizam, se vamos colocar jumbo frets em nossos necks para obter maior sustain, comentamos sobre os tipos de bridge que mais gostamos, entre outros assuntos.

Não está entendendo nada desse assunto? Não esquenta, somente nós guitarristas (malucos) entendemos. Essa é a nossa linguagem, a que usamos normalmente para comunicar nossas ideias e nossa paixão pela música.

Imagine uma situação hipotética, na qual esse grupo de amigos tivesse encomendado a uma equipe de programadores um sistema de controle de guitarras, um software no qual pudéssemos encontrar e colocar todo o tipo de informação pertinente da nossa área de atuação. De que modo você pensaria em modelar esse sistema? Qual seria um design apropriado para esse problema?

Um programador com linguagem puramente técnica tentaria explicar como desenvolveria o sistema usando DAOs, controladores, queries, Design Patterns e outras coisas que nada tem a ver com a área (apenas me deixando preocupado se ele realmente teria entendido) o negócio que gostaríamos de ver solucionado.

De outra forma, um programador poderia aproveitar o nosso vocabulário para modelar uma solução que usasse a nossa linguagem como apoio para o design. Nesse modelo, ele me mostraria como criaria guitarras, pickups, tremolos e repositórios diretamente na solução. Deixaria bem claro como esses elementos estão associados usando a mesma linguagem que nós utilizamos normalmente. A essa linguagem damos o nome de ubiquitous language.


Repare onde a ubiquitous language naturalmente se encontra, um meio-termo que une especialistas em domínio com especialistas em tecnologia:

A ubiquitous language é fundamental para o Domain Driven Design, metodologia que foca na construção de sistemas a partir do desenvolvimento (e isolamento) de um rico domain model, capaz de resolver problemas com eficiência e apoiado na linguagem que os usuários utilizam no dia a dia.

Eric Evans nos dá a direção:

"Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communications within the team and in the code. Use the same language in diagrams, writing, and especially speech. Recognize that a change in the ubiquitous language is a change to the model."

Nós devemos ser capazes de desenvolver sistemas que comuniquem bem seu design para os usuários que realmente o utilizarão. Mantenha apenas o modelo, código e testes como artefatos permanentes do desenvolvimento. Use a linguagem no dia a dia e a incorpore em todo o lugar, dos diagramas de classe aos códigos Java e C#. Isole o domain model e deixe o aparato técnico para ser discutido apenas por especialistas em tecnologia.

Próximos posts veremos como a arquitetura DDD é feita de forma a permitir o isolamento desse domain model.