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 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:
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.
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.
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.
Postagens
