Impressões iniciais sobre Arquitetura Orientada a Serviços

Acredito que SOA tenha sido um dos termos de uso mais abrangente em termos de tecnologia empregada a negócios nos últimos anos. Há atualmente uma diversidade de interpretações que, usualmente, levam a confusões. Para tentar esclarecer o tema, poderia dividir alguns comentários em dois grupos:

• O que não é SOA
• O que é SOA.

O Que Não É SOA:

• SOA não é software, ESB (Enterprise Service Bus), Web Services, Middleware, etc. De fato, questões tecnológicas como essas são importantes, mas não essenciais quando falamos de um projeto SOA. O uso de Web Services, por exemplo, é meramente uma escolha tecnológica para a implementação de um projeto SOA.
• SOA não é Integração de Sistemas. Projetos de integração de sistemas pretendem resolver problemas de baixo nível de abstração e relacionados a questões tecnológicas. Por exemplo: exposição de transações CICS em mainframe para outros ambientes, importação/exportação de dados em sistemas ERP, etc. Tipicamente, projetos SOA, para sua melhor implementação, fazem uso da infraestrutura de integração oferecida. Em outras palavras, projetos SOA presumem que a infraestrutura de integração já exista e esteja operando. Caso não exista, um projeto SOA pode (e deve) levar ao início de um novo projeto (ou subprojeto) de integração de sistemas.

O Que É SOA:

• SOA (como a sigla indica) é uma arquitetura. Simples assim. Nem mais, nem menos. Entretanto não é uma arquitetura de hardware, software, tampouco de rede. É uma arquitetura de Serviços de Negócio. Para definirmos um Serviço de Negócio é importante considerarmos o contexto onde ele está inserido. No mercado financeiro, alguns exemplos de Serviços de Negócio são: Cálculo de Juros, Análise de Risco, Transferência de Valores, etc. Já na indústria de Telecomunicações temos "Fulfillment", Aprovisionamento, etc.

Um projeto SOA, então, deve ser responsável por diversos aspectos como, por exemplo:

• Identificação de Serviços de Negócio. Os exemplos citados acima são simples e óbvios. Certamente há uma quantidade considerável de outros Serviços de Negócio que existem nas companhias e que necessitam ser identificados.
• Relacionamento entre Serviços de Negócio. Este aspecto deve especificar como os Serviços de Negócio interagem entre si, quais os domínios de Serviços de Negócio existentes, etc.
• Uso da infraestrutura tecnológica existente. Aqui sim haverá uma análise de "gap" entre os requerimentos dos Serviços de Negócio e o conjunto tecnológico existente na companhia (leia-se legado). Este "gap" não é uma tarefa simples pois deve considerar não somente os requerimentos funcionais dos Serviços de Negócio mas também os não-funcionais ou níveis de serviços como escalabilidade, disponibilidade, segurança, etc. Deste modo, por exemplo, pode-se imaginar que seja requerido que um Serviço de Negócio tenha característica de disponibilidade 24x7 e que, entretanto, os sistemas legado, usados por este Serviço não tenham sido construídos para atender esse requerimento.

Como conclusão, é importante que projetos de SOA não sejam considerados um fim, mas um meio. O fim deve ser, necessariamente, a melhoria do negócio da companhia através de maior agilidade, redução de custos, eventuais novas linhas de receita, etc