O mercado SOA parece as duas crianças. Alguns fornecedores dizem que tem SOA, que os outros não tem, e por aí vai. Mas afinal, o quê eu preciso ter exatamente no meu produto para dizer que ele tem SOA? Quais características ele deve ter para ser caracterizado como um produto SOA?
As respostas não são tão simples quanto parecem. Alguns fornecedores colocam suporte a webservices no seu sistema e dizem que tem SOA. Outros colocam webservices também, e além deles, fazem o sistema orientado por processos, funcionando com workflow (de preferência com suporte a BPEL), desacoplado, ligado a um ESB.. e dizem que tem SOA. Ambos estão certos, mas em níveis diferentes.
Lembro de um slide apresentado pela IBM em uma palestra que assisti, que mostrava umas 50 áreas que são de alguma forma afetadas pela arquitetura (nunca se esqueça disto: SOA é uma arquitetura) SOA. Desde o desenvolvimento, interface com o usuário, integração, processos, governança, workflow, etc.. é muita coisa.
Me parece que temos pelo menos dois níveis de SOA claramente distintos:
- SOA-Enabled: Aplicações que não são concebidas de acordo com a arquitetura SOA, mas que acabam se integrando ao ambiente SOA. Normalmente são aplicações legadas, monolíticas, que recebem uma "casca" de webservices, expondo suas principais funcionalidades.
- SOA-Based: São aplicações concebidas de acordo com as boas práticas SOA desde o princípio.
Um comentário:
O produto era uma tesoura do Mickey.
E não é por nada, mas eu tinha hehehe
http://img.mercadolivre.com.br/jm/img?s=MLB&f=63776222_4587.jpg&v=I
Postar um comentário