Já que o post anterior gerou comentários pedindo as respostas das perguntas, vamos tentar elaborar os tópicos. O primeiro é “Qual a Diferença entre Serviços e Componentes Distribuídos?”.
Vamos primeiro tentar entender o que chamamos por Componentes Distribuídos. Componentes são artefatos de software reutilizáveis, baseados nos princípios de engenharia eletrônica. Se você não sabe o que são componentes eletrônicos, abra seu computador (após ler este artigo!) e olhe todos aqueles quadradinhos pretos na placa-mãe.
Os Componentes possuem uma interface bem definida e oferecem operações aos seus clientes. Um Componente pode ser substituído por outro que obedeça a um contrato compatível com o publicado por sua interface. Para substituir um Componente, precisamos alterar o processo de lookup, quando um componente obtêm uma referência para o outro.
Componentes podem ser reaproveitados em outros sistemas que necessitem utilizar as mesmas operações já providas por este. A arquitetura baseada em componentes é chamada CBD - Component-Based Development.
Basicamente, ao criar um Componente você agrupa diversos objetos em um pacote com uma interface definida. os objetos não precisam ter responsabilidade semelhante, o que diferencia Componentes de Camadas, mas você pode usar Camadas para implementar os internos de um Componente. Camadas também não são necessariamente reutilizáveis, aliás é muito raro que o sejam.
A idéia é obter economia de escala, reutilizando um Componente eternamente sem precisar reimplementar aquela funcionalidade. CBD pode ser visto como um OO de maior granularidade, já que classes também são criadas para serem reutilizáveis (apesar de existirem malucos que criam suas próprias java.lang.String).
Componentes Distribuídos expõem suas interfaces numa rede. Eles deixam de ser internos à aplicação que os ‘publica’ (disponibiliza) e passam a oferecer suas operações na rede. EJB, por exemplo, é uma tecnologia criada com foco na criação deste tipo de componente.
Distribuído ou não, um Componente possui seu contrato onde estão publicadas as Operações que este disponibiliza. Qualquer um que saiba trabalhar com este contrato consegue utilizar o Componente.
Um Serviço é algo bem parecido fisicamente. É uma unidade de software que recebe mensagens. A diferença neste nível é na granularidade da mensagem recebida pelo Serviço. Enquanto o Componente recebe pequenas mensagens, o Serviço recebe uma ou pouco mais grandes.
Outra diferença básica é que um Componente possui um contrato que define suas operações, mas num Serviço os contratos são por operação. Isso quer dizer que para usar uma operação disponibilizada por um Serviço você não precisa conhecer as outras operações que este também oferece e, mais ainda, que as operações podem ser movidas de um Serviço para outro e só é necessário modificar os seus consumidores, e geralmente uma arquitetura SOA automatiza este tipo de modificação com indireção criada através de ESBs, por exemplo.
Claro que como quase tudo em tecnologia estes conceitos não são verdades absolutas. Dependendo da bibliografia, do fabricante ou do dia da semana os conceitos mudam bastante. Por enquanto fixe a diferença entre CBD e SOA nestes pontos:
- CBD tem mensagens com granularidade fina e síncronas
- SOA Tem granularidade grossa e mensagens geralmente assíncronas
- Em CBD a unidade atõmica de reusabilidade é o Componente
- Em SOA a unidade atômica de reusabilidade é cada operação
E quando implementamos um Serviço com um componente distribuido? (implementar um webservice usando ejb) como eles devem ser chamados? hehe
eu concordo totalmente com os 4 pontos apresentados(as bolinhas no fim)
mas eu também vejo o servico como algo mais abstrato e o componente como algo mais concreto..
ja que podemos implementar um servico usando um componente por tras.. dessa forma o servico seria uma camada antes do componente.. hehe
ja discuti muito isso na minha empresa e nao chegamos a lugar algum.. mas é interessantissima a discussao!
parabens pelo blog.. muito bom!
Ei, não é proque você usa EJBs, que usa componentes, *muito* pelo contrário. A maioria das aplicações que utilizam EJBs têm uma infra-estrutura pronta para CBD, mas não fazem nada parecido com isso.
Você, como dito no artigo, pode utilizar componentes para implementar serviços mas mantêr um mapeamento 1-1 entre eles vai fazer você ou ficar com CBD em vez de SOA ou SOA em vez de CBD.
Beleza, mas se pegarmos um “legítmo” componente implementado em EJB e colocarmos uma camada webservice sobre ele temos um serviço.
Por isso pra mim o Serviço é algo mais “abstrato”, ate porque um componente EJB só “fala” com java e o Serviço teoricamente fala com qualquer linguagem!
por exemplo, se falam pra voce “temos um serviço para calculos financeiros” você certamente nao se preocupa com a implementação dele (JAVA, C#.. etc..)
se alguem te fala o mesmo mas fala em componente.. voce vai se prender a tecnologia (EJB? COM+?)
Acho que não consegui explicar isso direito no primeiro comentário.. hehe
No fundo.. as diferenças existem e voce apontou algumas delas(talvez todas), mas eu quero passar que pra mim e muita gente.. qdo se fala em Componentes e serviços existem essas associações..
tecnologia, plataforma, interoperabilidade..
Não é porque você tem uma interface SOAP/WebServices que você tem serviços, não é porque você tem EJBs que tem componentes e não é porque você tem uma linguagem OO que programa OO. A tecnologia ajuda, mas não te impede nem guia a utilizar qualquer paradigma.
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 ;)
é uma discussao interessante!
e eu concordo com sua resposta.. mas na mairoria dos casos EJBs sao considerados componentes e Webservices sao considerados serviços.. e existe uma razão..
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
Hmm… pode ser mas eu acho que você está superestimando o conhecimento de OO da população desenvolvedora ;)
SOA é pura tecnologia? Não quero usar frases emblemáticas do mercado, mas SOA trata do alinhamento da TI com os processos de negócio da empresa.
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
Gustavo, CBD também não era pura tecnologia, ia prover o alinhamento e tudo mais. Modelagem de processos, orquestação… tudo isso já existia em CBD.
No que deu?
Não consigo ver quase nada de novo em SOA, exceto conceitos de CBD reeditados numa caixinha de anos 2000.
Ok, mas tem um detalhe que faz toda a diferença: a cultura do workflow - já forte no ambiente corporativo em que atuo hoje.
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.
Oi, Gustavo,
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 ;)
Oi, Phillip.
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.
Mas então, gustavo, nada impede que um componente tenha as tais operações que existem do pontod e vista da perspectiva do negócio. Na verdade na bibliografia que mencionei isso já é falado nos anos 90, incluindo BPM, orquestração e tudo mais.
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).