Certificação SOA

Com tantas certificações existentes no mercado, estava na hora de começar as primeiras certificações para SOA. Este post aqui fala sobre 3 certificações existentes (ao menos nos Estados Unidos, não sei se estão disponíveis aqui no Brasil): da IBM, da BEA e da ZapThink (nunca tinha ouvido falar desta última).

Enquanto as duas primeiras certificações citadas acima acabam focando mais nos seus produtos, a da ZapThink é totalmente agnóstica (tecnologicamente falando), focada apenas em SOA mesmo.

O post completo você encontra aqui, com mais descrições sobre cada uma das certificações.

10 formas de se comprovar que não é SOA

Joe McKendrick, colunista da ZDNet, escreveu o seguinte artigo no seu blog, o qual faço uma tradução livre abaixo.

1. Se algum vendedor te disser que você precisa comprar uma suíte para ter SOA.. então não é SOA.   SOA significa total liberdade de suítes e pacotes de aplicativos.
2. Se algum vendedor estiver tentando te vender algum hardware para ter SOA.. então não é SOA. Já diz tudo...
3. Se você fica mandando pedidos por e-mail ou fazendo ligações para descobrir quais serviços existem... então não é SOA. Registries e repositórios são essenciais para descoberta e validação de serviços.
4. Se ninguém está compartilhando serviços... então não é SOA. Você pode ter todos os serviços que você precisa, mas se os serviços ficam isolados em silos, então são apenas serviços em silos mesmo.
5. Se os desenvolvedores e integradores não são incentivados ou persuadidos e reutilizar serviços e interfaces... então não é SOA. Sem incentivos, eles vão continuar desenvolvendo seus próprios serviços.
6. Se o seu CIO não tem a menor idéia do que acontece com os serviços, se eles estão sendo ou não compartilhados... então não é SOA. Para funcionar corretamente, estruturas SOA-Based devem abranger todos os setores da empresa, e é necessário apoio gerencial para que isto aconteça. Do contrário, voltamos aos serviços em silos.
7. Se o pessoal de TI está comandando todo o show... então não é SOA. Desculpem, pessoal de TI, mas SOA necessita de um alto envolvimento do pessoal de negócios também.
8. Se é compatível apenas com um Sistema Operacional ou plataforma... então não é SOA. SOA não tem nada a ver com apenas um Sistema Operacional.
9. Se a implantação é uma réplica de outra de SOA de algum outro local... então não é SOA. Cada companhia tem seus próprios processos e requisitos de negócio, então duas implementações SOA não serão iguais.
10. Se você teve que re-escrever ou reprojetar fontes para fazer as coisas funcionarem corretamente... então não é SOA. SOA pressupõe que re-escrever o código deve ser desnecessário.

É lógico que não existe o SOA perfeito... o importante é a empresa se orientar para o mundo SOA em algum nível.

Meus comentários: 

Discordo de alguns itens acima:

• Do item 8 (apenas um Sistema Operacional): Posso ter tudo executando em apenas um Sistema Operacional e atender 100% SOA.
• Do item 10 (Se re-escrever, não é SOA): deste eu discordo fortemente. Em muitos casos, acho que na maioria deles, se não mexer no código vou ter apenas um sistema SOA-Enabled (SOA compatível apenas). Para ser SOA-Based (um SOA "de verdade") quase certamente precisarei re-escrever os programas de acordo com a nova arquitetura. Não se esqueça nunca: O "A" de SOA é de Arquitetura! 

Eu tenho, você não tem!

Os mais err.. "experientes" devem se lembrar de uma propaganda antiga, na qual uma das crianças tinha um produto e ficava falando pra outra, que não tinha: "Eu tenho, você não tem! Eu tenho, você não tem!". Não me lembro qual era o produto, mas o slogan eu não me esqueci. Aliás, se você lembrar do produto, poste nos comentários... ;-)

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.

Nenhum dos fornecedores citados está mentindo quando diz que tem SOA. Você só deve ficar atento e ver o quê exatamente ele tem de SOA na sua aplicação.

SOA

Opa, tá na hora de falar alguma coisa sobre SOA (afinal, este blog era para falar disto, né? :-)). Por enquanto, só um basicão:

O que é SOA? SOA é a sigla para Service Oriented Architecture, ou seja: Arquitetura Orientada a Serviços. 

SOA não é um produto empacotado e pronto ("Me vê uma cópia do Windows, um Office 2007 e um SOA"), SOA não é uma tecnologia simplesmente, SOA não é um "conjunto de webservices".. SOA é uma ARQUITETURA que deve ser corporativa (impacta na empresa toda) e que serve para interligar serviços de negócio que podem ser reutilizados e compartilhados entre aplicações e empresas.

SOA utiliza várias tecnologias para sua utilização: BPMN, BPEL, Webservices, XML.. Vou entrar mais em detalhes de cada uma delas em futuros posts. E vou falar mais sobre SOA mesmo, também, pois afinal, o assunto é extenso e impacta em ferramentas, metodologias, gerenciamento...