Comments for SOA Corporativa http://www.soacorporativa.com.br Tornar estratégias de negócios em ação Sat, 13 Mar 2010 02:10:58 +0000 http://wordpress.org/?v=2.5.1 Comment on Anatomia do Serviço (Taxonomia básica) by admin http://www.soacorporativa.com.br/2008/06/03/anatomia-do-servico-taxonomia-basica/#comment-169 admin Mon, 29 Jun 2009 14:06:04 +0000 http://www.soacorporativa.com.br/?p=36#comment-169 Raoni, repositórios são importantes, mas o assunto tem um âmbito bem maior. Sobre modelagem você pode encontrar <a href="http://www.soacorporativa.com.br/2008/11/21/projetando-servicos-referencias/" rel="nofollow">aqui</a>, <a href="http://www.aqueleblogdesoa.com.br/2008/12/projeto-de-servicos-contratos-camadas-e-eda/" rel="nofollow">aqui </a>e <a href="http://www.aqueleblogdesoa.com.br/2008/10/anatomia-do-servico-parte-2/" rel="nofollow">aqui</a>. Recomendo inicialmente os livros de Thomas Erl. Quando você define “tipos” de serviços, você está elaborando sua arquitetura. Com isso você pode organizar, por exemplo, como distribuir suas regras de negócio (divisão por domínio, isolar regras de conectividade, entre outras possibilidades), garantindo os princípios SOA. []´s Gustavo Raoni, repositórios são importantes, mas o assunto tem um âmbito bem maior.

Sobre modelagem você pode encontrar aqui, aqui e aqui. Recomendo inicialmente os livros de Thomas Erl.

Quando você define “tipos” de serviços, você está elaborando sua arquitetura. Com isso você pode organizar, por exemplo, como distribuir suas regras de negócio (divisão por domínio, isolar regras de conectividade, entre outras possibilidades), garantindo os princípios SOA.

[]´s Gustavo

]]> Comment on Anatomia do Serviço (Taxonomia básica) by Raoni http://www.soacorporativa.com.br/2008/06/03/anatomia-do-servico-taxonomia-basica/#comment-168 Raoni Sun, 28 Jun 2009 16:09:48 +0000 http://www.soacorporativa.com.br/?p=36#comment-168 Gustavo, não discordo que um serviço composto é um serviço composto de vários outros, de que o de processo é um processo que executa vários serviços e assim vai, mas qual o critério para definirmos tipos de serviços? Sem duvida classificação de serviço tem muitos benefícios, foi como eu disse na questão de um repositório de serviço. Mas a classificação deve ser feita através de algo que orienta a construção da solução e nem sempre esse tipo de classificação pode ser útil, para que se torne um padrão. Vamos analisar um caso mencionado por você. “Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. “ Temos um fluxo de negocio, onde uma atividade de “cadastrar usuário”, necessita da execução de um serviço já existente, se tivermos 10 serviço com as classificações de Serviço Básico, Serviço Composto e Serviço de Processo. Qual seria a responsabilidade de cada um? Como eles estão restringindo algo? O que essas classificações ajudariam na minha modelagem? Qual classificação é equivalente a cadastrar usuário? É bem mais sensato deixarmos que uma gerencia de configuração caracterize eles, do que definirmos essas nomenclaturas como padrão, por exemplo com a gerencia de configuração podemos saber onde buscar fisicamente o serviço requerido (servidor, repositório...), quem é responsável por manter ele funcionando ou adicionar regras (arquiteto, equipe de desenvolvimento...), quem tem permissão de usá-lo(setor x, setor y...), como posso acessar esse serviço (ws, ejb...) podemos definir tipos de acordo com negocio da empresa (Serviços Financeiro, Serviços Administrativo, Serviços de Calculo, Serviços de Solicitação, Serviços de Produção, Serviços de Estoque...) e assim vai. Concordo com você que esses nomes dados são tipos de serviço, se partimos do ponto de vista de como eles são feitos, agora não entendo o porque de limitar esses tipos em de processo, composto, básico, de negocio e integração. Se essa classificação colaborar com o gerenciamento apoio o uso (sem restrições caso seja identificado outro tipo), senão, não vejo a obrigação de usá-los. Talvez isso fique mais claro pra mim se tiver um critério para definir tipos de serviços. []s Gustavo, não discordo que um serviço composto é um serviço composto de vários outros, de que o de processo é um processo que executa vários serviços e assim vai, mas qual o critério para definirmos tipos de serviços?
Sem duvida classificação de serviço tem muitos benefícios, foi como eu disse na questão de um repositório de serviço. Mas a classificação deve ser feita através de algo que orienta a construção da solução e nem sempre esse tipo de classificação pode ser útil, para que se torne um padrão. Vamos analisar um caso mencionado por você.
“Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. “
Temos um fluxo de negocio, onde uma atividade de “cadastrar usuário”, necessita da execução de um serviço já existente, se tivermos 10 serviço com as classificações de Serviço Básico, Serviço Composto e Serviço de Processo. Qual seria a responsabilidade de cada um? Como eles estão restringindo algo? O que essas classificações ajudariam na minha modelagem? Qual classificação é equivalente a cadastrar usuário?
É bem mais sensato deixarmos que uma gerencia de configuração caracterize eles, do que definirmos essas nomenclaturas como padrão, por exemplo com a gerencia de configuração podemos saber onde buscar fisicamente o serviço requerido (servidor, repositório…), quem é responsável por manter ele funcionando ou adicionar regras (arquiteto, equipe de desenvolvimento…), quem tem permissão de usá-lo(setor x, setor y…), como posso acessar esse serviço (ws, ejb…) podemos definir tipos de acordo com negocio da empresa (Serviços Financeiro, Serviços Administrativo, Serviços de Calculo, Serviços de Solicitação, Serviços de Produção, Serviços de Estoque…) e assim vai.
Concordo com você que esses nomes dados são tipos de serviço, se partimos do ponto de vista de como eles são feitos, agora não entendo o porque de limitar esses tipos em de processo, composto, básico, de negocio e integração. Se essa classificação colaborar com o gerenciamento apoio o uso (sem restrições caso seja identificado outro tipo), senão, não vejo a obrigação de usá-los. Talvez isso fique mais claro pra mim se tiver um critério para definir tipos de serviços.
[]s

]]> Comment on Anatomia do Serviço (Taxonomia básica) by admin http://www.soacorporativa.com.br/2008/06/03/anatomia-do-servico-taxonomia-basica/#comment-166 admin Fri, 26 Jun 2009 20:46:19 +0000 http://www.soacorporativa.com.br/?p=36#comment-166 Raoni, compreendo o que você falou, mas concordo apenas em um ponto: contratos bem definidos são essências tanto no âmbito de negócio ou tecnológico. A classificação dos serviços traz benefícios interessantes, principalmente quando você define o tipo de back-end que serviço encapsula. Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. Gosto dessa classificação: http://www.soamethodology.com/p5.asp Considerações sobre seu comentário: "Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço." Não estou considerando tecnologia e sim princípios SOA. Você pode ter 3 tipos de serviços e usar diversas tecnologias diferentes. "- O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço." Serviços são “pedaços de software” coesos e com interfaces bem definidas. Não vejo muita diferença entre um componente de negócio e um serviço. Na verdade, SOA tem muitos dos princípios de CBD. Componentes de negócio, coesos, pouco acoplados e com uma interface bem definida, são serviços. A classificação ajuda entender como foi modelado. "- Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço." Um serviço composto é exatamente isso: um serviço que acessa outros serviços. Ou seja, a classificação ajuda entender como foi modelado. "Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados." Novamente, não estou considerando tecnologias, apenas princípios SOA. Não é relevante se você está usando WS ou EJB. Raoni, compreendo o que você falou, mas concordo apenas em um ponto: contratos bem definidos são essências tanto no âmbito de negócio ou tecnológico.

A classificação dos serviços traz benefícios interessantes, principalmente quando você define o tipo de back-end que serviço encapsula. Auxilia principalmente no processo de modelagem, impondo restrições e dividindo responsabilidades, organizando seus serviços. Gosto dessa classificação: http://www.soamethodology.com/p5.asp

Considerações sobre seu comentário:

“Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço.”

Não estou considerando tecnologia e sim princípios SOA. Você pode ter 3 tipos de serviços e usar diversas tecnologias diferentes.

“- O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço.”

Serviços são “pedaços de software” coesos e com interfaces bem definidas. Não vejo muita diferença entre um componente de negócio e um serviço. Na verdade, SOA tem muitos dos princípios de CBD. Componentes de negócio, coesos, pouco acoplados e com uma interface bem definida, são serviços. A classificação ajuda entender como foi modelado.

“- Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço.”

Um serviço composto é exatamente isso: um serviço que acessa outros serviços. Ou seja, a classificação ajuda entender como foi modelado.

“Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados.”

Novamente, não estou considerando tecnologias, apenas princípios SOA. Não é relevante se você está usando WS ou EJB.

]]> Comment on Anatomia do Serviço (Taxonomia básica) by Raoni http://www.soacorporativa.com.br/2008/06/03/anatomia-do-servico-taxonomia-basica/#comment-165 Raoni Fri, 26 Jun 2009 15:28:33 +0000 http://www.soacorporativa.com.br/?p=36#comment-165 Olá Gustavo, Eu já tinha visto na Internet alguma coisa falando sobre esses tipos de serviços, porem eu acho um pouco destorcida essa denominação, “Tipo de Serviços”. No meu ponto de vista, serviços são serviços e pronto e o que está sendo chamado de “tipo” seria a forma (implementação) de como ele foi feito por detrás do contrato. Serviço é um mecanismo que permite acessar uma ou mais funcionalidades, esse acesso deve ser fornecido por um contrato. Na verdade o que deveria importar é esse tal de contrato e não a forma de como ele é feita. Se você utiliza um serviço para executar a atividade de um processo de negocio, não importa como é feito o serviço para o negocio e sim como vai se conectar.(Importa em nível de infra-estrutura corporativa, não em nível de serviço.) Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço. - O que está sendo chamado de “Serviço de Processo” é uma orquestração de serviço utilizando processo, exposta como serviço, para ser acessada por uma atividade de um outro processo... Olha que complexidade desnecessária para falar que uma atividade acessa um serviço. - O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço. - Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço. Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados. Abraço Raoni Gomes Olá Gustavo,

Eu já tinha visto na Internet alguma coisa falando sobre esses tipos de serviços, porem eu acho um pouco destorcida essa denominação, “Tipo de Serviços”. No meu ponto de vista, serviços são serviços e pronto e o que está sendo chamado de “tipo” seria a forma (implementação) de como ele foi feito por detrás do contrato.
Serviço é um mecanismo que permite acessar uma ou mais funcionalidades, esse acesso deve ser fornecido por um contrato. Na verdade o que deveria importar é esse tal de contrato e não a forma de como ele é feita. Se você utiliza um serviço para executar a atividade de um processo de negocio, não importa como é feito o serviço para o negocio e sim como vai se conectar.(Importa em nível de infra-estrutura corporativa, não em nível de serviço.)

Se partirmos pelo principio abordado, podemos concluir que hoje temos um numero X de tipo de serviços e esse X é igual ao numero de tecnologias no mercado que é capaz de construir uma funcionalidade que pode ser exposta como serviço.

- O que está sendo chamado de “Serviço de Processo” é uma orquestração de serviço utilizando processo, exposta como serviço, para ser acessada por uma atividade de um outro processo… Olha que complexidade desnecessária para falar que uma atividade acessa um serviço.
- O “Serviço de Negocio” como você escreveu no texto alguns autores usam o nome de componente de negocio, simplesmente porque ele é um componente de negocio. Então ele se torna em um Serviço de Negocio quando esse componente de negocio é exposto como serviço.
- Acessar vários serviços através de um serviço, não é “tipo” de serviço e sim orquestração e/ou coreografia, logo no contexto usado “Serviço Composto” é uma orquestração e/ou coreografia exposta como serviço.

Então se eu faço uma funcionalidade em Java e exponho ela como serviço seria um “Serviço Java”? Se essa é a abordagem dos autores concordo plenamente, mas se não for, qual é a definição de um “tipo de serviço”? Porque que falar como o serviço é feito é essencial para o sucesso da abordagem? Acredito que esse sucesso e maturidade da utilização de serviço dentro da empresa chegarão quando a empresa tiver um repositório de serviço com políticas bem definidas, e ai a classificação pode ser feito de qualquer forma, contando que o uso dos serviços sejam facilitados.

Abraço

Raoni Gomes

]]> Comment on Promover serviços legados ou organizar a casa? by Gustavo S. Sinis http://www.soacorporativa.com.br/2009/05/26/promover-servicos-legados-ou-organizar-a-casa/#comment-159 Gustavo S. Sinis Tue, 02 Jun 2009 18:29:20 +0000 http://www.soacorporativa.com.br/?p=61#comment-159 Oi Suzanny, obrigado pelo comentário. Pensar no que pode ser aprimorado, substituído ou descartado envolve questões muito variadas, cada empresa possui uma realidade. De qualquer forma, é preciso sempre considerar os processos de negócio (visão do todo) e proporcionar o alinhamento com a TI, neste âmbito que SOA contribui. SOA fornece abstrações modulares que ajudam na organização e no alinhamento com o negócio proporcionando agilidade. Os serviços SOA - abstrações aderentes aos conceitos do negócio - possibilitam que a evolução do código e o entendimento dos conceitos relativos ao negócio caminhem no mesmo sentido, ou seja, o código só sofre mudanças em grandes proporções se o negócio também mudar significativamente. SOA Cria uma “topologia” corporativa aderente ao negócio. Se o negócio mudar pouco, seus sistemas deveriam mudar proporcionalmente, não de forma imprevisível. Os serviços também funcionam como um vocabulário comum entre a TI e o negócio, facilitando a comunicação. Com a abordagem, você pode relacionar seus serviços com os processos principais da empresa (que geram valor para os clientes) e com as metas estratégicas, justificando, por exemplo, investimentos. Para obter esses benefícios, os processos de negócio devem ser analisados. Mesmo quando a decisão for manter o legado, os serviços SOA (aderentes ao negócio) podem contribuir muito para organizar e aprimorar o legado. Portanto, uma consultoria especializada em SOA, não em integrações, é essencial para lidar com o legado. []´s Gustavo Oi Suzanny, obrigado pelo comentário.

Pensar no que pode ser aprimorado, substituído ou descartado envolve questões muito variadas, cada empresa possui uma realidade. De qualquer forma, é preciso sempre considerar os processos de negócio (visão do todo) e proporcionar o alinhamento com a TI, neste âmbito que SOA contribui. SOA fornece abstrações modulares que ajudam na organização e no alinhamento com o negócio proporcionando agilidade.

Os serviços SOA - abstrações aderentes aos conceitos do negócio - possibilitam que a evolução do código e o entendimento dos conceitos relativos ao negócio caminhem no mesmo sentido, ou seja, o código só sofre mudanças em grandes proporções se o negócio também mudar significativamente. SOA Cria uma “topologia” corporativa aderente ao negócio. Se o negócio mudar pouco, seus sistemas deveriam mudar proporcionalmente, não de forma imprevisível.

Os serviços também funcionam como um vocabulário comum entre a TI e o negócio, facilitando a comunicação. Com a abordagem, você pode relacionar seus serviços com os processos principais da empresa (que geram valor para os clientes) e com as metas estratégicas, justificando, por exemplo, investimentos.

Para obter esses benefícios, os processos de negócio devem ser analisados. Mesmo quando a decisão for manter o legado, os serviços SOA (aderentes ao negócio) podem contribuir muito para organizar e aprimorar o legado. Portanto, uma consultoria especializada em SOA, não em integrações, é essencial para lidar com o legado.

[]´s Gustavo

]]> Comment on Realidade do ESB sem SOA by Blog do Pantoja » Blog Archive » Falando em Java 2009 - Eu fui.. (Meus comentários..) http://www.soacorporativa.com.br/2008/10/22/realidade-do-esb-sem-soa/#comment-157 Blog do Pantoja » Blog Archive » Falando em Java 2009 - Eu fui.. (Meus comentários..) Wed, 27 May 2009 12:48:44 +0000 http://www.soacorporativa.com.br/?p=53#comment-157 [...] para TV Digital.A Palestra do Jim clareou algumas idéias que eu tinha a respeito de SOA mostrou a realidade do ESB, tais como vantagens de usar Web Services RESTFull. Jim Webber deixou um artigo sobre o assunto na [...] [...] para TV Digital.A Palestra do Jim clareou algumas idéias que eu tinha a respeito de SOA mostrou a realidade do ESB, tais como vantagens de usar Web Services RESTFull. Jim Webber deixou um artigo sobre o assunto na [...]

]]> Comment on Promover serviços legados ou organizar a casa? by Suzanny Lavor http://www.soacorporativa.com.br/2009/05/26/promover-servicos-legados-ou-organizar-a-casa/#comment-156 Suzanny Lavor Tue, 26 May 2009 21:23:23 +0000 http://www.soacorporativa.com.br/?p=61#comment-156 Olá, seu post é bastante enriquecedor! Estou vivenciando um cenário na minha empresa de análise do que deve ser reutilizado ou não. Gostaria de saber sua opinião acerca dessas dúvidas: - O que é necessário para fornecer agilidade, flexibilidade e o reuso estratégico do legado na organização? - O que é necessário para oferecer mais eficiência e agilidade na disponibilização de soluções de software, com baixo custo no desenvolvimento? - A agilidade e flexibilidade apregoada por SOA melhoram o relacionamento e promovem melhor alinhamento entre negócios e TI? Abraço! Olá, seu post é bastante enriquecedor!
Estou vivenciando um cenário na minha empresa de análise do que deve ser reutilizado ou não.
Gostaria de saber sua opinião acerca dessas dúvidas:
- O que é necessário para fornecer agilidade, flexibilidade e o reuso estratégico do legado na organização?
- O que é necessário para oferecer mais eficiência e agilidade na disponibilização de soluções de software, com baixo custo no desenvolvimento?
- A agilidade e flexibilidade apregoada por SOA melhoram o relacionamento e promovem melhor alinhamento entre negócios e TI?

Abraço!

]]> Comment on Projeto de serviços: contratos, camadas e EDA. by SOA Corporativa » Blog Archive » Promover serviços legados ou organizar a casa? http://www.soacorporativa.com.br/2008/12/17/projeto-de-servicos-contratos-camadas-e-eda/#comment-155 SOA Corporativa » Blog Archive » Promover serviços legados ou organizar a casa? Tue, 26 May 2009 18:36:59 +0000 http://www.soacorporativa.com.br/?p=58#comment-155 [...] Abstração está intimamente relacionado com encapsulamento. Portanto, encapsular o legado com serviços bem projetados é [...] [...] Abstração está intimamente relacionado com encapsulamento. Portanto, encapsular o legado com serviços bem projetados é [...]

]]> Comment on Realidade do ESB sem SOA by SOA Corporativa » Blog Archive » Promover serviços legados ou organizar a casa? http://www.soacorporativa.com.br/2008/10/22/realidade-do-esb-sem-soa/#comment-154 SOA Corporativa » Blog Archive » Promover serviços legados ou organizar a casa? Tue, 26 May 2009 18:36:37 +0000 http://www.soacorporativa.com.br/?p=53#comment-154 [...] Com freqüência, vejo o seguinte ponto preocupante em eventos relacionados com SOA: promover a reutilização de todo o legado. Atualmente, com ferramentas de integração e bons repositórios, ficou relativamente fácil sair reutilizando o legado. No entanto, isso deveria ser feito seguindo alguns princípios SOA. Promover a reutilização do legado sem considerar esses princípios, promove a complexidade de forma proporcional (30 anos de silos e espaguete não somem por mágica). [...] [...] Com freqüência, vejo o seguinte ponto preocupante em eventos relacionados com SOA: promover a reutilização de todo o legado. Atualmente, com ferramentas de integração e bons repositórios, ficou relativamente fácil sair reutilizando o legado. No entanto, isso deveria ser feito seguindo alguns princípios SOA. Promover a reutilização do legado sem considerar esses princípios, promove a complexidade de forma proporcional (30 anos de silos e espaguete não somem por mágica). [...]

]]> Comment on Realidade do ESB sem SOA by Projeto de serviços: contratos, camadas e EDA. - Aquele blog de SOA http://www.soacorporativa.com.br/2008/10/22/realidade-do-esb-sem-soa/#comment-153 Projeto de serviços: contratos, camadas e EDA. - Aquele blog de SOA Wed, 17 Dec 2008 14:06:32 +0000 http://www.soacorporativa.com.br/?p=53#comment-153 [...] Contudo, serviços bem identificados não bastam. Serviços devem ter o máximo de independência possível. Pensar serviços em termos de camadas traz benefícios importantes, pois essa abordagem pode evitar que seus serviços fiquem parecidos com a figura abaixo. Usar uma ferramenta ESB não resolve. [...] [...] Contudo, serviços bem identificados não bastam. Serviços devem ter o máximo de independência possível. Pensar serviços em termos de camadas traz benefícios importantes, pois essa abordagem pode evitar que seus serviços fiquem parecidos com a figura abaixo. Usar uma ferramenta ESB não resolve. [...]

]]>