Você sabe o que é SOA?

Depois de um bom tempo sem postar, devido a falta de tempo mesmo, resolvi escrever este post sobre um assunto até certo ponto simplório, mas que após a leitura deste verão que apresenta grande impacto e significância. Cada vez mais enxergo grandes empresas estando mais atentas sobre o que é realmente ter SOA, e do ponto de vista das empresas prestadores de serviço de TI, o que é realmente um serviço baseado em SOA.

Em suma, SOA é uma forma de se fazer software. Ponto. Qualquer definição super-mega-hyper mirabolante que fale o contrário estará deliberadamente querendo tornar um conceito simples em algo complexo apenas para parecer complexo, ou porque se parecer complexo, o serviço ou produto vendido poderá ter um preço mais alto. Neste ponto, critico as atuais empresas de TI sobre como elas estão conduzindo erroneamente a questão SOA em seus clientes.

Por trás de qualquer movimento cujo foco é SOA, sempre há um projeto de software. Na essência, não existem projetos SOA, existem projetos de software tradicionais que, segundo a vontade e adotar SOA, aplicam certas atividades e fases especiais no ciclo de vida de projeto. Por exemplo, num projeto relacionado a gestão de fluxo de caixa, algumas fases, disciplinas, atividades e papéis típicos de projeto podem ser modificados e alguns criados para subsidiar a cultura SOA no projeto.

Mais ainda, um projeto que diz-se estar usando SOA deve ter algumas premissas de projeto sendo aplicadas, durante o ciclo de vida do mesmo. Aqui vai algumas dicas sobre o que NÃO é um projeto SOA típico:

• Projetos que não aplicam iterações focadas na disciplinas de federação de dados;
• Projetos que não aplicam iterações focadas no catálogo de XML schemas corporativos;
• Projetos que não possuem mecanismos de UDDI para catálogo de serviços;
• Projetos que não são baseados em processos, sejam executáveis ou BPM;
• Projetos que não aplicam segurança corporativa, por exemplo, usando os Patterns Gateway e Token Service
• Projetos que não aplicam gestão do conhecimento, subsidiando processos como ativos

Neste caso, repare que muitos dos grandes mitos sobre SOA não foram comentados, em especial:

• Que para se ter SOA, deve-se usar Web Services. Pode-se ter um projeto SOA baseado em CORBA / IIOP!
• Que para se ter SOA, deve-se usar um ESB. Um barramento FACILITA questões de integração, mas não é imperativo. Se o custo com EAI for calculado como baixo, ou se a plataforma corporativa é homogênea o suficiente para não precisar de questões de integração, para que enfiar um ESB no projeto?
• Que para se ter SOA, deve-se usar BPEL. BPEL é uma excelente linguagem de processos executáveis, mas dependendo da natureza dos processos consumidos pela aplicação ele jamais irá resolver. BPEL não garante máquina de estados, premissa básica para qualquer processo de negócio que tenha tarefas humanas. Se o processo for 100% sistêmico, BPEL pode ser usado sim, mas ele não é sinônimo de SOA, nunca!
• Que para se ter SOA, deve-se utlizar a ferramenta XPTO do fabricante XYZ. Nenhuma solução SOA está amarrada a uma tecnologia. Dos poucos projetos realmente SOA que conheço, a plataforma tecnologica foi tão heterogênea que acredito que uma parceira dos principais fabricantes de soluções SOA seria saudável.

Quando tiver mais tempo livre, irei postar mais informações sobre este mundo SOA. Tenho, profissionalmente me engajado em alguns projetos importantes que me dão algum conhecimento a mais sobre este mundo focado em serviços, mas atualmente me falta tempo para escrever este conhecimento e compartilhar com todos. Até a próxima!