Putz!! A parte 1 é de 03/Nov!!! Q relaxo...

Bom, a 1a parte reclamou da "sopa de letrinhas hipercomplexa" que caracteriza o universo SOA (culpa dos fornecedores).

Agora o 2o "culpado": NÓS!! Explico:

SOA (Services-Oriented Architecture) exige que tratemos SOFTWARE de uma forma diferente. Por "tratar" entenda-se:

.Desenvolvimento
.Aquisição
.Manutenção / Evolução

Infelizmente o núcleo da questão gira em torno d'um termo que devíamos aposentar por desgaste: reusabilidade. Um "Serviço" só faz sentido se reutilizado. Aí esbarramos em dois grandes problemas:

1) Objetos de negócios (agora, "Serviços") precisam ser compostos de forma a facilitar sua reutilização. Demanda afeta diretamente os "usuários" e "analistas de negócios";

2) Programador detesta reutilizar código. Mito ou verdade? 50/50.

Só que SOA não faz sentido sem reutilização. Artigo de David Chappell mostra como SOA pode, finalmente, fazer a tal "reusabilidade de código" vingar.

Muita gente tá apostando que 2005 será o "Ano SOA". Não acredito. Ainda mais falando exclusivamente de pindorama. Se os estadunidenses andam preocupados com a disponibilidade de profissionais devidamente preparados, o que dizer da gente?

Casos de sucesso (gente fazendo grana com algo) costumam acelerar o ciclo de adoção de tecnologias/conceitos/padrões. A Amazon é uma grande plataforma de serviços web. E criou uma teia que tá fazendo muita grana girar. Não sabia?