Artigo Engenharia de Software 2 - CBD x SOA

Projeto

CBD x SOA

Serviços, processos de negócio e componentes que realizam os serviços

Muitas comparações já foram feitas entre desenvolvimento orientado a objetos (OO) e o desenvolvimento baseado em componentes (CBD). Componentes e objetos, possuem características similares, como a necessidade de interfaces bem definidas e a disponibilização de operações aos seus clientes. Essas semelhanças dificultam ainda mais o entendimento de OO e CBD. Algo muito parecido vem acontecendo no caso de CBD e SOA.

Como veremos, existem conceitos de CBD e SOA similares, por exemplo, encapsulamento, contratos e reuso, que podem dificultar a comparação dessas abordagens. Para uma melhor comparação é necessário compreender os conceitos essenciais envolvidos, quais sejam, processos de negócio, componentes realizadores dos serviços, entre outros.

O presente artigo não trata de tecnologia, como “REST versus SOAP/WS”, ou “serviços implementados com EJB/RMI”. Atualmente, existe uma infra-estrutura tecnológica pronta, que suporta o desenvolvimento OO + CBD + SOA sem muito esforço, mas não garante, apenas permite a aplicação das abordagens citadas. Web Services não são necessariamente SOA, e EJB não é necessariamente componente. Uma comparação de CBD x SOA é muito abrangente e, portanto, envolve questões de várias dimensões. Sendo assim, este artigo focará nos serviços que refletem os processos de negócio. Isto porque, é apenas nesse âmbito que o SOA pode cumprir sua promessa de alinhar TI com negócio.

SOA: evolução, não inovação

Desconfie quando alguém fala que uma abordagem em TI é totalmente nova, pois, normalmente, as novidades do mercado complementam ou corrigem as antigas, e não as substituem. Soluções como CBD e SOA se destinam, na maioria das vezes, a superar limitações humanas, como lidar com grande quantidade de informações complexas. Para lidar com tal complexidade, a abstração é uma ferramenta chave, e está intimamente relacionada com o conceito de encapsulamento. Focando nesse aspecto essencial, Page Jones descreve em seu livro “Fundamentals of Object-Oriented Design in UML” os níveis de encapsulamento. Baseando-se nesses níveis, é possível partir de simples linhas de código e chegar ao SOA, passando por CBD, mesmo considerando que essas abordagens foram concebidas em contextos diferentes. Para uma visão geral desses dois conceitos, observe o esquema da Figura 1. 

Figura 1. Esquema dos níveis de encapsulamento com serviços

No início, eram apenas linhas de código e vários GOTOs. Quem já programou assim lembra que, muitas vezes, face à necessidade de se fazer uma alteração, era mais fácil recodificar o programa inteiro em função da desorganização que existia. Além disso, para realizar qualquer manutenção, era preciso memorizar todo o código envolvido.

Com a adoção de sub-rotinas (primeiro nível de encapsulamento), foi possível reaproveitar as linhas de código. Estas linhas, encapsuladas através de uma sub-rotina, podiam ser chamadas quantas vezes fossem necessárias. Além disso, usava-se a decomposição funcional, ou seja, um problema era dividido em problemas menores (sub-rotinas) sucessivamente, e depois, as operações eram agrupadas em módulos lógicos. Infelizmente, a maioria das hierarquias de sub-rotinas geradas com essa abordagem não são suficientemente independentes para garantir reuso ou alterações controladas, pois, existe um acoplamento forte e sem controle. Assim, apenas esse nível de encapsulamento deixava a manutenção cara em ambientes com aplicações numerosas ou complexas. Neste caso, uma alteração no código poderia afetar de forma imprevisível todo o sistema, sendo necessário testá-lo novamente por completo.

Com a dificuldade na manutenção que a decomposição funcional provocava em sistemas grandes ou complexos, em determinado momento da história os dados passaram a ser o centro das aplicações, pois era possível mantê-los de forma relativamente estável. O código era tratado como algo descartável, ou seja, muito pouco esforço era feito para criar um código de qualidade e garantir o reuso no desenvolvimento. Dessa forma, o banco de dados passou a ser o centro de tudo. O efeito colateral dessa abordagem foi muita replicação de código.

Em função das limitações da abordagem de decomposição funcional, fez-se necessária a criação de mais um nível de encapsulamento: a classe. Nessa abordagem, as “sub-rotinas” e os “dados” estão em uma única estrutura. Os “dados” são protegidos através das “sub-rotinas”, e os “dados” também são objetos. Para uma definição um pouco mais formal, temos que citar a retenção do estado e a identidade única. Na abordagem OO, o foco está em atribuir responsabilidades (comportamento) coesas e para cumprir tais responsabilidades, os objetos trocam mensagens entre si. O paradigma orientado a objetos busca meios de diminuir o “gap semântico”. Em outras palavras, diminuir a distância entre o problema no mundo real e o modelo abstrato construído.

Com a estratégia de “dividir para conquistar”, e também inspirado nos princípios da engenharia eletrônica, foi criado mais um nível de encapsulamento, qual seja, o componente de negócio. O componente encapsula objetos, protegendo-os com uma interface, de maneira contratual. O uso de contrato (Design by Contract) implica que cada uma das operações do componente é definida em termos de sua assinatura (seus tipos de argumentos de entrada e saída) e de suas pré-condições e pós-condições. Um componente oferece funcionalidades, por meio de interfaces bem definidas, para o meio externo. Componentes de negócio são subsistemas projetados para serem reutilizáveis corporativamente, mas a reutilização não é a única motivação. A necessidade de lidar com modificações de maneira rápida e controlada tornou-se essencial atualmente.

Serviços são parecidos com componentes em muitos aspectos, por exemplo, a ênfase em interfaces.  Contudo, ele é a representação lógica de uma tarefa de negócio repetitiva que tem um resultado específico (por exemplo, verificação de crédito dos clientes e fornecer dados meteorológicos). Uma abordagem promissora mostra serviços sendo encontrados diretamente em processos de negócio. SOA é um estilo arquitetônico, que suporta a orientação a serviços, com foco nos processos de negócios. Para uma definição formal, veja o site The Open Group (http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632). O desenvolvimento baseado em componente fornece uma base experimentada e testada para a implementação de SOA. Pode-se considerar que serviços, no caso do SOA, encapsulam componentes.

Conceituando SOA

Martin Fowler descreve a confusão em torno de SOA em um post no seu bliki, de leitura obrigatória, chamado Service Oriented Ambiguity (endereço relacionado no quadro Links). O cientista sustenta que é impossível responder o que é SOA, pois, para pessoas diferentes, SOA possui significados distintos. Entretanto, podemos relacionar algumas idéias e mitos recorrentes na conceituação de SOA, que, juntos, podem auxiliar na definição de tal estratégia - SOA é uma estratégia de TI para melhor atender o negócio e não apenas um projeto de desenvolvimento ou algumas ferramentas. Não existe SOA, por exemplo, se a empresa possui apenas um sistema.

Um dos principais erros na conceituação de SOA atualmente, mostra SOA como pura tecnologia, por exemplo, Web Services e EJBs. SOA tem dois aspectos fundamentais: a necessidade de se mapear processos e de ter governança SOA. Sem esses elementos não é possível obter os benefícios com SOA. 

Considerando que as empresas são grandes coleções de processos e que SOA promove o alinhamento com o negócio, concluímos que existe uma forte conexão entre os processos de negócios e a identificação de serviço. Em geral, os processos de negócios concentram-se nas tarefas repetitivas executadas em uma seqüência lógica. As tarefas, em uma organização, realizam alguma meta, freqüentemente para fornecer valor na forma de produto ou serviço para uma parte externa, como um cliente ou um parceiro. O serviço é a representação desta tarefa de negócio repetitiva. O mesmo está relacionado intimamente com o processo de negócio e possibilita que ele seja um vocabulário comum entre TI e as áreas de negócio, facilitando a comunicação. O negócio é a base para a identificação de serviços, e, para a identificação ser efetiva, cada processo precisa ser modelado.

Governança SOA é focada no ciclo de vida dos serviços. Governança SOA estende a Governança de TI para assegurar os conceitos e princípios de SOA. Em outras palavras, é uma especialização de Governança de TI. A Governança SOA endereça questões como: Maturidade dos Serviços; Infra-estrutura para a gerência dos serviços; Educação e Treinamento; Regras e Responsabilidades; e Mudanças organizacionais.

Freqüentemente, relaciona-se SOA à integração de sistemas, o que não condiz com a realidade. Basta observar que EAI (Enterprise Application Integration) surgiu com o objetivo principal de resolver os problemas da integração ponto a ponto, também conhecido como “spaghetti integration”, fornecendo um meio uniforme de integração, SOA tem ambições muito maiores. Além disso, EAI possui características algumas vezes conflitantes com SOA, como o fato de ser centrado em dados e não em processos e de não se direcionar pelo negócio. O que motiva a criação de um serviço não é a integração ponto a ponto. Entretanto, SOA dá grande ênfase às interfaces que, quando bem definidas, “facilitam” a integração e, até mesmo, o reuso de código. Para atender as necessidades de integração no contexto de SOA, evitando integração ponto a ponto, temos o Enterprise Service Bus (ESB). O ESB é um conceito, com algumas características de EAI, que fornece uma camada para a lógica de integração de serviços. Existem ferramentas para ESB que disponibilizam uma infra-estrutura flexível de conectividade para integração de aplicações e serviços, suportando SOA. O ESB tem como característica: roteamento de mensagens entre serviços; conversão de protocolos de transporte entre requisitante e serviços; transformação do conteúdo de mensagens entre o requisitante e o serviço; Mensagens Síncronas e Assíncronas (ver Figura 2).