CBD era uma palavra sem hype e inventaram outra para reinventar os mesmos conceitos. Acho que a diferença real é que CBD abriga vários tipos de componentes e SOA geralmente se refere á serviços mais Model Driven (mas isso não é uma obrigação, Thomas Erl e derivados deixam claro os papéis de um Serviço de infra-estrutura ou os tais serviços-base que não possuem mapeamento 1-para-1 com conceitos do negócio).

Eu não disse que as interfaces de componentes são sempre pouco granulares. “Com CBD, tem-se na interface do componente todas as operações necessárias para “realizar” os UCs” - na verdade, podemos considerar os UCs como soluções para os requisitos funcionais, que produzem um resultado observável para um ator. Na descrição dos UCs, temos as interações ator/sistema. Analisando essas interações, encontramos, por exemplo, a necessidade de exibir uma simples lista (para uma caixa de seleção) ou, até mesmo, coisas do tipo “aprovar um empréstimo”.

A afirmação “já com SOA, há serviços apenas se observados na perspectiva do negócio” estava falando especificamente de serviços encontrados nos processos de negócio; a Rational tem alguns métodos para isso, onde está o maior valor do SOA. Nessa abordagem, o serviço depende do negócio, ou seja, tem de ser significativo para o processo de negócio.

Serviços encontrados com uma “análise dos processos de negócio” facilitam a vida de quem faz orquestração no contexto de BPM.

Componentes não precisam ter interfaces pouco granulares e Serviços não
possuem necessariamente granularidade de negócio.

CBD poderia ter preparado a casa para SOA se algum dia tivesse sido implantado, o que no fim das contas nunca aconteceu (mesmo com a disponibilidade tecnológica de EJBs e ORBs). Na minha opinião SOA enquanto baseado em SOAP/WS-* vai pro mesmo buraco, o único SOA ue tem chance é o que utiliza ferramentas simples, como REST.

E cuidado: BPM sempre existiu, a demanda também, mas CBD não foi implantado por isso ;)

Nada do CBD foi revogado com SOA, pelo contrário, CBD trouxe uma forma de organizar a casa, para termos serviços depois. Concorda? A diferença é que, com CBD, tem-se na interface do componente todas as operações necessárias para “realizar” os UCs; já com SOA, há serviços apenas se observados na perspectiva do negócio. Em outras palavras, a existência de um serviço só faz sentido se o mesmo estiver associado a uma atividade no workflow.

Essa abordagem ajuda, principalmente, em questões como a orquestração no contexto de BPM e a justificativa de investimentos em TI, uma vez que permite a visibilidade da associação do serviço com o negócio. “O negócio não pede SOA”, contudo, vejo uma demanda grande por BPM, o que, por conseguinte, também atrai a demanda por SOA.

No que deu?

Não consigo ver quase nada de novo em SOA, exceto conceitos de CBD reeditados numa caixinha de anos 2000.

Os serviços devem ser rastreáveis, pode-se identificar sua origem no negócio, ou seja, tudo começa nos processos de negócio da empresa. Por isso temos uma granularidade grossa nos serviços.

As técnicas para encontrar serviços partem sempre da análise do processo. Não existe uma relação direta de uma atividade do processo com um serviço (1 para 1), mas ele sempre está relacionado, no final da análise do negocio (processo), a uma atividade.

Os serviços encontrados com essa abordagem podem ser “realizados” a partir do uso de componentes de negócio. SOA não tem como objetivo, por exemplo, o Reuso, nem EAI. Mas, a fim de se dar suporte ao negócio, é claro que se passa, indiretamente, por muitas dessas questões tecnológicas.

http://www.iasahome.org/web/home/featurememberarticle

justamente porque eu ainda acho, e acredito que a maioria das pessoas ache tambem, que as definições de componentes e serviços ainda nao estão muito claras e difundidas..

se voce perguntas oq sao serviços e componentes para 10 pessoas talvez as 10 nao deem uma explicação clara como a sua.. ao passo q se vc perguntar o que é OO para 10 pessoas 8 vao explicar direito o que é.. talvez as 10 saibam explicar OO

No caso específico de EJBs, você pode tranquilamente conversar via SOAP, CORBA, RMI ou mesmo outra interface mais exótica com outros sistemas em outras plataformas.

Na verdade, uma das grandes ‘vantagens’ da versão 3 de CORBA foi exatamente o suporte a componentes interoperáveis. Aquia v4:

http://www.omg.org/technology/documents/formal/components.htm

Como o texto fala você pode, e geralmente vai (em Java EE), implementar serviços com ajuda de componentes, a diferença reside no paradigma utilizado para a modelagem, não na tecnologia. Estou atualmente na fase final de arquitetura de um sistema totalmente SOA com interfaces em EJB/RMI.

Algo que eu não quis mencionar no texto para não confundir mais, mas é muito importante é que algumas correntes de CBD (e.g. Herzun/Sims) já tinham todos estes conceitos e previram muito sobre o que seria SOA em 2000, só que o nome utilizado por estes era Enterprise Distributed Component (EDC), em oposição aos System-Level Components (SLCs) que são o que conhecemos como componentes de maneira geral.

Bem, mas este último tópico está sendo gaurdado para outro artigo ou ainda uma palestra sobre o tema que devo ministrar me breve ;)

tecnologia, plataforma, interoperabilidade..