Aquele blog de SOA

Pessoal,
uma das formas mais legais que já vi de ilustração sobre erros comuns em SOA.
Post escrito pelo Frank Kenney, mandando muito bem, pra variar.

Fiz um copy completo do post, que não dá pra resumir sem perder a graça! Visita obrigatória no blog de origem.

Ahh Shucks, SOA Is A Failure

November 12th, 2008 ·Frank Kenney

Yea, I feel your pain. So much time effort and money put into SOA and it is a complete a dismal failure. Sorry to have misled you. Daryl Plummer and I are deep in depression. Sucks to be us. Oh well here’s some free advice to help you get by. In fact I will make this very easy for you. All you have to do is copy and paste the following, substituting your name for the big red XXXX.

——————————————————————————cut here

To the CIO, CEO, CFO, CTO and shareholders,

As a result of the following I can now only deduce that SOA is a failure and any attempts at SOA will result in failure. Under my direction:

• I have failed to associate our SOA initiatives with our business needs, therefore I cannot show any value for the hundreds of services we have created ,
• I have failed to properly create and support an SOA Center of Excellence, Steering Committee or Competency Center,
• I have failed to enlist the executive staff as true supporters and evangelistscfor our SOA efforts.
• I chose to buy an ESB prior to truly understanding our SOA infrastructure needs (In reality this wasn’t my fault, the vendor said it was super duper necessary)
• I have failed to provide my developers incentives to reuse artifacts,
• It was not my responsibility to follow what was going on next door where there was a separate team dealing with BPM, I mean they are two different initiatives,
• I firmly believe that SOA is nothing more than fancy CORBA or COM.

Despite all of the things I have NOT done, SOA has failed. My additional failure to recognize and implement best practices that have been proven successful in many other companies worldwide also play into the failure of SOA.

Oh well, we should move on and try something new. On the bright side 70% of our initiatives fail anyway. The failure of SOA is SOA’s fault not mine.

Thanks for understanding and I’d like to declare in advance that Cloud Computing, Virtualization and SaaS will be failures under my direction as well.

Thanks for listening

XXXX

Project Manager, EA Artchitect, Lead Developer (Choose One)

———————————————————————-cut here

Email this to the largest DL you can find, and rejoice in the fact that you are not alone. Many others feel the same way.

-f

P.S. You failed, not SOA. Now go resign.

PS: Repasse esta carta para um amigo arquiteto!

PS2: L. Frank Kenney (http://blogs.gartner.com/frank_kenney/) is a Research Director for Applications Strategy and Governance in Gartner Research, where he is responsible for research in the governance of SOA infrastructure initiatives, Web services, business-to-business integration software, strategies, methodologies and technologies including SOA, EDI, FTP and XML.

• Read More »

A discussão sobre riscos de segurança com adoção de SOA remete a uma discussão ainda maior: sobre a necessidade de uma preparação inicial (interna) nas empresas antes de se aventurar em projetos SOA. Eu, particularmente, tenho uma opinião forte de que não dá para rodar um primeiro projeto corporativo com Arquitetura Orientada a Serviço sem antes definir uma série de mecanismos arquiteturais que amenizem alguns riscos.

Exemplos: Mecanismo de Segurança de Serviços, Mecanismos de testes de serviços, Mecanismo de controle de “runtime Policies”,  etc…

Para as empresas que fizeram o dever de casa, estruturaram seu grupo de arquitetura (ou núcleo SOA), evoluiram a Arquitetura de referência e criaram seus mecanismos arquiteturais e de governança, essa preocupação é bem menor…

Abaixo, dois trechos interessantes falando sobre um dos fatores críticos na adoção de SOA: segurança.

——

Segurança desencoraja uso de SOA e webservice

Silvia Balieiro, da Info CORPORATE
12/11/2008

SÃO PAULO - Na opinião de executivos de TI, o uso de SOA e webservices traz muitos riscos à segurança das empresas.

A informação vem de uma pesquisa global encomendada pela CA. Os números apontam que 43% dos executivos de TI classificam as ameaças à segurança como o item mais crítico na implementação de SOA e de webservices.

Os profissionais entrevistados disseram ter enfrentado uma média de sete ataques ao XML relacionado à Arquitetura Orientada a Serviço (SOA) e ao webservice no ano passado. 57% dos pesquisados admitiram já ter adiado ou atrasado algum projeto desse gênero devido à preocupações com segurança.

Outro dado do estudo mostra que, para 93% dos homens de TI é fundamental a integração do SOA e dos webservices com as soluções de gestão de acesso e identidade. E 43% desses profissionais já fizeram essa integração.

—

Segurança é ponto crítico em SOA e serviços web

fonte: TI Inside: http://www.tiinside.com.br/News.aspx?ID=102376&C=262

“A questão de segurança é a principal preocupação das empresas na tomada de decisões em relação a implementação de arquitetura orientada a serviços (SOA, na sigla em inglês) e de serviços de Web. De acordo com uma pesquisa global, patrocinada pela CA, 43% dos executivos sênior de TI classificam as ameaças à segurança como o item mais crítico na implementação de aplicações de SOA e de serviços baseados na Web.”

• Read More »

Sistemas possuem diversas necessidades. Para apoiar o negócio, sistemas precisam executar regras de negócio, fluxo do processo de negócio, lógica de conectividade, persistir dados em algum lugar. Por isso, aplicações são divididas em camadas, deixando esses aspectos mais organizados (apresentação, aplicação, negócios, infra-estrutura), possibilitando que alterações sejam contidas, por exemplo, alterações simples na apresentação ou na persistência não obriguem que quase todo o sistema seja alterado como conseqüência direta.

Pensando corporativamente, a situação fica mais complicada. Processos de negócio atravessam diversas áreas e sistemas de uma empresa, obrigando constantes integrações. Muitos sistemas duplicam regras de negócio e é necessária uma lógica de conectividade muito complexa.

Para evitar que pequenas alterações no processo de negócio ou em regras de negócio sejam inviabilizadas, obrigando grandes alterações em diversos sistemas, algumas abordagens são necessárias como, por exemplo, CBD, DbC, SOA. Essas abordagens, assim como camadas, lidam com limitações humanas, por exemplo, memória limitada dificultando a manutenção de processos grandes e complexos, mas com um foco corporativo.

SOA busca agilizar alterações no processo de negócio, dividindo sistemas em serviços que possibilitam a separação da lógica do processo de negócio da logica do domínio. Podemos considerar serviços como interfaces que definem uma topologia corporativa. Obter serviços bem projetados é o principal desafio.

Abordagens como SOA evitam o desenvolvimento baseado em silos (que misturam todo tipo de lógica):

Simplesmente ligar todos esses silos criando pontes (ESB) no estilo “mega construções” da discovery não resolve o problema. Como mostra Jim Webber, Ph.D., Global Architecture Lead, ThoughtWorks.

A bagunça continuaria (muito acoplamento), muitas vezes, escondida dentro de um ESB. Algo parecido com isso:

Serviços bem projetados são essenciais, principalmente serviços que ajudam a separar a lógica de regras de negócio da lógica dos processos de negócio, possibilitando uma evolução mais independente.

Contamos com serviços básicos que encapsulam regras de negócio, representando um conceito principal da corporação (isolando um domínio específico), evitando duplicidade de regras e acoplamento de conceitos de negócio importantes.

Contamos também com serviços que orquestram esses serviços mais básicos, criando uma indireção, para atender uma tarefa do processo de negócio, ou ainda, para publicar algum passo do UC que precisa ser corporativo.

O processo de negócio, muitas vezes instanciado com ajuda de linguagens como BPEL, orquestra todos tipos de serviços.

Thomas Erl classifica como SOA contemporâneo os serviços que seguem princípios específicos, quais sejam: a reutilização; o contrato formal; o baixo acoplamento; a autonomia; entre outros. Serviços servem a propósitos diferentes e desempenham papéis muito distintos. A classificação dos serviços em uma corporação é essencial para o sucesso da abordagem.

Existem várias formas de categorização de serviços, considerando o tipo de lógica encapsulada, o potencial de reutilização, a origem, os domínios existentes e a segurança, entre outros. Existem vários autores com abordagens diferentes; Thomas Erl, por exemplo, define algumas classificações em seu livro. Exemplos: Application Service; Business Service; Controller Service; Coordinator; Entity-centric business sevice; Integration service; process service; task-centric business service; Utility Service; Wrapper service;

Há três classificações de serviço principais definidas por Erl - usando uma abordagem em camadas:

– Entidade

Representa conceitos principais em uma organização, também conhecidos como serviços básicos por alguns autores. Uma rede hoteleira, por exemplo, poderia ter um Serviço Hotel. Esse serviço teria como responsabilidade obter apartamentos disponíveis e ocupar apartamentos. E, ainda, poderíamos ter um Serviço Cliente, para tratar questões coesas com clientes.

É considerado um serviço altamente reutilizável porque é agnóstico a maior parte dos processos de negócio. Algumas técnicas de identificação de componentes de negócio podem auxiliar na identificação deste serviço.

– Tarefa

Representa uma tarefa do processo de negócio. Este tipo de serviço tende a ter menor potencial de reutilização (mas com grande ganho quando reutilizado) e geralmente é responsável por “orquestrar” serviços de Entidade. Além disso, é responsável por garantir a pré-condição dos serviços que “orquestra”.

Um serviço de reserva, por exemplo, poderia ser uma tarefa de um processo maior, ficando responsável por “orquestrar” os serviços Cliente (capacidade: verifica cliente aprovado) e Hotel (capacidade: ocupar apartamento) para efetuar a reserva. O SOMA, metodologia da IBM para SOA, fornece estratégias interessantes para a identificação destes serviços.

– Utilitários

Serviços não associados diretamente ao processo de negócio e também não associados aos conceitos principais corporativos. Exemplos: retorna se um ano é bissexto; converte unidades de medida. Também podem assumir um caráter mais tecnológico ou de infra. Possuem alta reutilização.

Serviços bem projetados são essenciais para SOA, no entanto, não podemos esquecer que uma arquitetura provada (mecanismos funcionando e consolidados) e uma governança bem definida (com quem eu reclamo se meu serviço cair? como encontrar serviços?) também são essenciais.

Continuação dos posts: anatomia do serviço parte 1 e parte 2.

• Read More »

Pessoal, um post aproveitando a discussão sobre a crise x SOA. Agora com uma visão mais otimista.

**********************************************************************

Karl-Heinz Streibich, CEO da companhia, estima surgimento de novas e mais exigências regulatórias podem impulsionar avanço dessas tecnologias.
Por Fabiana Monte, do COMPUTERWORLD*
04 de novembro de 2008 - 15h38

O CEO da Software AG, Karl-Heinz Streibich, acredita que atual instabilidade econômica mundial é uma boa oportunidade para impulsionar a adoção de SOA, BPM e BAM, devido ao possível surgimento de novas exigências regulatórias no sistema financeiro e em outras industrias.

“TI será uma ferramenta para garantir o compliance regulatório de forma rápida e com o menor custo possível”, afirmou o executivo durante o Innovation World, evento promovido pela Software AG em Miami.

Para Streibich, temas como compliance e gerenciamento de riscos ganharão ainda mais foco com a crise financeira. Por isso, a implementação de políticas individuais de gerenciamento de risco, por meio de SOA e BPM, será uma vantagem competitiva não apenas para instituições financeiras, mas para companhias com atuação em todas as indústrias.

Na visão do CEO da Software AG, a adoção de SOA permite as empresas um melhor posicionamento para realizar fusões, aquisições. “SOA é a Perestroika da indústria de TI”, exagerou Streibich.

• Read More »

Neste post, meu amigo Giscard Fernandes nos oferece a sua visão prática sobre SOA, seu relacionamento com tecnologias importantes como RFID e IMS. Giscard trabalha na NEC do Brasil, é um profissional respeitado no desenvolvimento de software para centrais telefônicas e RFID, possui experiência internacional em projetos no Japão e nos EUA.

• Read More »

E aí, pessoal? Vocês que estão no front, concordam com a visão do Gartner?

****************************************************************

Com crise, organizações adiam investimentos em SOA

A adoção da arquitetura orientada aos serviços perde velocidade rapidamente, segundo pesquisa do Gartner

Infoworld, EUA

Publicada em 04 de novembro de 2008 às 17h29

O número de organizações planejando adotar SOA caiu para 25% na pesquisa do Gartner sobre o tema em 2008. Para se ter uma idéia, esse número foi de 53% na pesquisa do ano passado.

Cresceu o número de organizações que não pensam em adotar SOA. De 7% em 2007 para 16% em 2008. A dramática queda de interesse em SOA, relata o Gartner, está acontecendo desde o início de 2008.

O instituto faz essa pesquisa há cinco anos e essa foi a primeira vez em que registrou queda nos números, disse Dan Sholler, vice-presidente de pesquisas no Gartner. “Estamos vendo organizações que, por várias razões, não pretendem fazer nada específico para SOA,” disse.

No geral, as organizações planejam menos projetos em 2009 e SOA também foi atingido.

O Gartner apontou uma mudança no que as empresas pensam sobre SOA. Se antes o conceito era visto como uma modificação inevitável para as corporações, a idéia está mudando. As empresas avaliam SOA e decidem não gastar tempo ou dinheiro nele.

O Gartner ouviu mais de 200 empresas durante os meses de maio e julho de 2008. Outras três pesquisas subseqüentes foram realizadas pelo instituto em conferências realizadas em várias partes do mundo, com 119 entrevistados.

• Read More »

O objetivo dessa série de posts é a fundamentação básica do mundo SOA.

Aqui no blog temos discutidos diversos tópicos avançados a respeito de SOA, e até mesmo por pedidos de alguns visitantes, segue aqui uma visão inicial do que seria a Arquitetura Orientada a Serviços, se tivéssemos que a definir em poucas palavras.

Esse post é escrito para aqueles que são iniciantes na abordagem de Arquitetura Orientada a Serviços. Recentemente essa área ganhou muito espaço no meio corporativo, com ela muitos são os conceitos presentes em documentos que tratam de SOA e para os iniciantes o assunto torna-se um bicho de sete cabeças.

Origem de SOA

O desenvolvimento de aplicações em ambientes corporativos ganhou, com o tempo, proporções que não poderiam ser previstas a curto prazo. Esse crescimento desordenado criou uma espécie de “colcha de retalhos” onde cada componente é desenvolvido para ligar 2 pontos específicos e possuem alto acoplamento dentro do sistema fazendo com que haja uma grande redundância de funcionalidades.

Arquitetura Tradicional

O que é acoplamento? É o nível de interdependência entre os módulos de um sistema. Por outro lado, um módulo é considerado coeso quando possui uma atividade bem definida. (veja mais)

Definição de Acoplamento

Diferentemente do que as pessoas pensam, SOA não se trata de uma simples invenção. A arquitetura orientada a serviços nada mais é que a evolução natural da arquitetura de sistemas tradicional para solucionar as necessidades de desenvolvimento e capacidade de adaptação às novas demandas de mercado, que se faz cada vez mais exigente em qualidade e agilidade.

Para os desenvolvedores isso significa ter que criar sistemas semelhantes com ajustes particulares para cada componente. Para as empresas isso significa dinheiro jogado fora, já que os componentes poderiam ter sido feitos voltados para o reúso.

O que SOA não é

Para reforçar a definição de SOA cabe deixar explícito o que não faz parte desse conceito. Para começar, vale deixar claro que SOA não é uma tecnologia. SOA é mais baseada em logística e conceitos e menos em ferramentas.

SOA não é um produto, portanto não é possível comprar SOA.

Os conceitos de Arquitetura Orientada a Serviços, WebServices, XML e BPM são relacionados no mundo SOA, mas são distintos no mundo de TI, portanto:

SOA != WebServices != XML != BPM

Definição de SOA

SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplicações e empresas.

Princípios Básicos de SOA

Segue abaixo uma lista com os 8 princípios básicos da Arquitetura Orientada a Serviços.

• Serviços são reutilizáveis;
• Serviços possuem baixo acoplamento;
• Serviços abstraem a lógica;
• Serviços são capazes de se compor;
• Serviços são autônomos;
• Serviços evitam alocação de recursos por longos períodos;
• Serviços devem possuir a capacidade de serem descobertos.

Em breve escreverei com mais detalhes sobre cada um deles.

Por fim, não posso deixar de agradecer a ajuda especial do Rafael no desenvolvimento do post!

Até a próxima.

[]’s

– Gabriel

• Read More »

Pessoal,

na última semana participei de um evento muito interessante no Rio de Janeiro. Um debate organizado por um grupo de interesse em BPM. O Grupo tem reuniões mensais para discussões relacionadas BPM, SOA e afins. Fui convidado para participar de um painel de discussão sobre SOA (Junto com representantes da Oracle e CPM) e rolou um bate papo muito legal.

Download da apresentação (clique na imagem)

Gostaria de agradecer ao Leo Borges e Fernando Botafogo pelo convite, e extender o agradecimento a todos os presentes no evento. Uma dinâmica muito interessante de discussão, usando questões previamente elaboradas pelo grupo e uma troca de experiência entre todos. Papo bom, digno de uma mesa de boteco.

Como prometi no evento, deixo disponível aqui a apresentação realizada (ou link na imagem).

Ao GI_BPM, parabéns por toda essa mobilização! Até a próxima reunião, estarei na platéia!

abraços,
Marcílio

• Read More »

Olá pessoal, já faz um tempinho que não ando postando nada. Mas agora estou de volta e com força total. Como já é de costume iremos falar um pouco mais sobre os assuntos técnicos relacionados a SOA. Este é o primeiro post de uma série de 4 que falaremos sobre alguns dos padrões emergentes para Web Services, os famosos WS-*. (O asterisco aqui quer dizer que existem vários padrões para Web Services, por exemplo: WS-Addressing, WS-BPEL, WS-Security e outros).

Nos meus últimos posts, discutimos sobre o Modelo de processamento SOAP e sobre a Anatomia do WSDL . Para quem não tem muita familiaridade com estes temas, recomendo fortemente a leitura destes dois posts antes de começar a ler esta série.

O primeiro padrão que falaremos é o WS-Addressing. Este padrão define construções em XML para dois tipos de informação: endpoint reference e message information. Estas informações são tipicamente de responsabilidade dos protocolos de transporte (ex: HTTP, SMTP). O padrão WS-Addressing normatiza estas informações dentro de um formato uniforme de modo que possa ser processado independentemente da camada de transporte. Mas afinal o que é um endpoint reference? Endpoint reference é uma entidade, recurso ou processador para onde as mensagens dos Web Services são encaminhadas, ou seja, um endpoint reference está para Web Services assim como URL e email estão para os protocolos HTTP e SMTP, respectivamente.

Um endpoint reference pode ser usado de duas maneiras: a primeira, para endereçar e referenciar o provedor do serviço e a segunda, para endereçar as mensagens transmitidas entre o consumidor e o provedor do Web Service (message information). Para isso, o padrão WS-Addressing define um bloco XML que deve estar contido dentro do header do envelope SOAP. O header geralmente contém informações auxiliares usadas para controlar segurança, transações e outros aspectos que não estão diretamente ligado a funcionalidade do Web Service.

A figura acima apresenta alguma das tags definidas pelo padrão WS-Addressing.
<MessageID> - Identificador da mensagem. Nenhuma mensagem de uma mesma aplicação pode ter o mesmo identificador. Se uma mensagem é retransmitida ela mantém o mesmo MessageID.
<ReplyTo> - Especifica o endpoint reference para onde deverá ser enviada a resposta para esta mensagem.
<To> - Especifica o endpoint reference destino desta mensagem.
<Action> - Identifica a semântica da mensagem. Em outras palavras, amarra a mensagem com o portType do WSDL identificando se a mensagem é um <input>, <output> ou <fault>.

Existem algumas API’s para Web Service que implementam este padrão (Apache CFX, JBOSS Native, Apache Axis 2 entre outros). Você deve está ser perguntando: por que eu preciso deste padrão? Simples, ele é base para outros padrões que veremos a seguir. Vou ficando por aqui, até a próxima pessoal.

• Read More »

Orquestração e coreografia são dois termos que causam muita confusão quando falamos de SOA, BPM e EAD. Já vi muitas pessoas usarem ambos os termos indiscriminadamente referindo-se a composição de serviços, ou seja, duas palavras tecnicamente diferentes utilizadas para dizer a mesma coisa. O grande agente desta confusão está na analogia que fazemos com a definição real das palavras. Segundo o dicionário Priberam as definições desses termos são:

• Orquestração: “ato ou arte de orquestrar.“
• Coreografia: “arte de conceber e notar os passos e as figuras dos bailados; arte da dança.“

É bem estranho quando levamos essas definições para o mundo de TI (SOA, BPM, EAD…). Aliás, a definição de Orquestração no dicionário não ajuda em nada. Será que os meus serviços dançam uns com os outros seguindo um ritmo com “passinhos” pré-determinados? Felizmente não é isso, então vamos explicar:

Orquestração

Em SOA/BPM orquestração é a composição de serviços para criar um novo serviço ou para resolver uma tarefa de um processo de negócio. Neste caso, sempre há a figura de um ponto central. Um serviço ou uma atividade de negócio que coordena a chamada de outros serviços para compor uma função de maior granularidade. A orquestração de serviços é análoga a um método da orientação a objetos que faz chamadas de outros métodos.

Coreografia

A coreografia já é pré-determinada antes da sua execução. Por exemplo, quando um serviço é acionado e envia uma mensagem, outros serviços podem estar programados de ante-mão para receber ou não essa mensagem e dispararem outras ações. Chamamos este processo de evento. Serviços são acionados conforme a classe de eventos que ocorrem. Característica básica da arquitetura orientada a eventos. Em um middleware é possível atribuir esta característica através da criação de fluxos Publish/Subscribe.

abraço,

- Fábio Rosato

• Read More »