Baixo Acoplamento (Loose Coupling) de Serviços

A falta de dependência entre os serviços (consumer e provider) é muito importante para um projeto de arquitetura SOA, por isso é muito importe que os serviços tenham um baixo acoplamento (Loose Coupling).

O baixo acoplamento é divido em 5 dimensões, conforme a seguir:

• Localização: Consumidores (service consumers) não devem ser dependentes da localização do serviço.  Por isso os serviços, para um máximo desacoplamento na dimensão da localização devem ser expostos em um ESB.

• Plataforma: Consumidores e Provedores (services consumers e providers) devem ser independentes de plataforma, por isso o uso de padrões aberto é importantíssimo nesta dimensão, fazendo com que plataformas diferentes como J2EE e .NET conversem uma com a outra sem saberem que estas estão interagindo com outra plataforma. 

• Linguagem: Nesta dimensão a preocupação é a mesma da dimensão plataforma. Por exemplo, o uso de Java object streams serializados pode ser altamente eficaz para certos consumidores e provedores, mas pode limitar o reuso porque algum ponto da arquitetura SOA evoluiu. O uso de formatos e protocolos abertos dentro da linguagem de programação é a melhor maneira de evitar o acoplamento. 

• Formato: Formatos proprietários ou feitos sob medida são utilizados por enumeras razões, mas introduzem uma dependência muito grande que se transforma em um obstáculo muito grande para uma arquitetura SOA flexível. Os formatos abertos, como SOAP, XML, etc. trazem o desacoplamento necessário para esta dimensão, por isso são altamente recomendados. Nem sempre é possível utilizar padrões de formatos abertos. Neste caso a utilização de um ESB expondo um formato proprietário como um formato aberto traz o desacoplamento necessário nesta dimensão. 

• Protocolo: Assim como os formatos, vários protocolos proprietários são utilizados. A solução para este dimensão dentro de uma arquitetura SOA é exatamente a mesma da dimensão formato, ou seja, a utilização de protocolos abertos, como SOAP over HTTP.
  

Camadas de Abstração

Há um grande número de frameworks que dividem a arquitetura em camadas de abstração. SOA traz um pequeno número de novas considerações e artefatos arquiteturais que devem ser adicionados aos frameworks existentes.

SOA é divido em 5 camadas de abstração:

• Camada Corporativa: Na camada corporativa são definidos os modelos de negócios da empresa (enterprise business model), como quais são seus principais processos baseados em seu objetivo e mercado.
  

• Camada de Processos: Na camada de processos, os processos do modelo de negócios são identificados. Cada processo é único para cada área funcional de negócio e pode ser composto por vários sub-processos. A camada de processos é muito importante dentro da arquitetura SOA, porque muitos processos podem ser modelados e executados como serviços. É comum a confusão entre as terminologias de “serviços” e “processos”. Processos são definidos uma única vez e usados dentro de um único contexto, já serviços também são definidos uma única vez, mas este pode ser reutilizado (reuso) em diferentes “processos”.
  

• Camada de Serviços: A camada de serviços é caracterizada por um número de serviços que realizam funções individuais de um negócio. Dentro da arquitetura SOA, esta camada fornece uma ponte entre as camadas de alto (camada corporativa e de processos) e baixo nível (camada de componentes e objetos). Usualmente, é nesta camada que as funções críticas necessárias para o negócio são identificadas, visto que é nela que usualmente são identificadas e expostas as funções para suportar o negócio.

• Camada de Componentes: Na camada de componentes são identificados e caracterizados os componentes que podem ser mapeados como serviços. Normalmente através de técnicas “bottom-up” (análise das aplicações e identificação de funções que podem ser serviços, por terem um potencial de reaproveitamento em vários sistemas).
  

• Camada de Objetos: A camada de objetos, estão as classes, atributos e relacionamentos de um objeto. Na arquitetura SOA há um reaproveitamento dos conceitos de orientação a objeto, porem com o desacoplamento dos objetos, transformando em serviços reutilizáveis.

Tipo de processamento... Quais opções nós temos?

Quando falamos de integração de aplicações, independente da abordagem utilizada (EAI, ponto a ponto, SOA, ETL, etc. ) um ponto fundamental que deve estar na análise é o tipo de processamento que será utilizado. A itenção aqui não é falar se uma é certa ou não, até porque na minha visão todas são... Tudo depende do requisito para se escolher o tipo mais adequado. As opções são:

• Processamento Batch: Processos executados em “lotes”. Em geral, os processos batch são processados em um determinado período (semanalmente, diariamente, de 5 em 5 horas, etc.). Atualmente, o uso de processos batch é freqüente em sistemas onde a carga de dados se faz necessária. Este tipo de processamento deve ser assíncrono.
  

• Processamento On-Line: Processos executados a cada interação. A atualização dos dados do processo são efetivadas no momento em que ocorrem o fato correspondente, porem o tempo de resposta pode ser ”indeterminado”. Este tipo de processamento pode ser síncrono ou assíncrono.
  

• Processamento Real Time: Processos executados a cada interação. A atualização dos dados do processo são efetivadas no momento em que ocorrem o fato correspondente, porem o tempo de resposta deve ser “determinado” (finito). Este tipo de processamento deve ser síncrono.
  

• Processamento Síncrono: Processo onde o resultado obrigatoriamente deve ser enviado para o sistema que requisitou, em um determinado período (time out), mesmo no caso de uma falha. Os dois sistemas envolvidos devem estar no ar. Exemplo: Páginas Web/Conexão HTTP.
  

• Processamento Assíncrono: Processo onde o resultado não precisa (mas pode) ser enviado para o sistema que requisitou, mesmo no caso de uma falha. Caso um sistema não esteja no ar, este não interfere no funcionamento do outro (Connection Less). Exemplo: E-Mail.

SOA sem governança?

Para quem está (seriamente) estudando, implementando ou implantou os paradigmas da abordagem SOA dentro de uma empresa, sabe que não existe a opção “sem governança” e PONTO FINAL.

Vejam alguns dos principais problemas que acontecem (notem que eu nem utilizei a frase “problemas que podem acontecer”):

• O potencial não é totalmente utilizado;
• Desenvolvimento e implantação sem padrões;
• Serviços são criados sem controle;
• Serviços são duplicados;
• Serviços são criados, porém as aplicações não os chamam… “Continua da maneira antiga”;
• Serviços não são reutilizados.

Mas da para ter uma “governança mínima”?

Muitas vezes, pessoas responsáveis pela implantação de SOA dentro de uma empresa me dão o seguinte argumento: Não tenho budget e/ou tempo para a implantação da governança SOA mas não quero perder a oportunidade de começar a implantar os conceitos, ferramentas, etc. O que faço? Bem, geralmente eu tenho duas respostas, cada uma de acordo com o meu humor na hora em que eu acordei:

• Quando acordo irado com o mundo digo: Desista!  

• Quando acordo um pouco mais simpático: Implante o mínimo de governança, criando pelo menos padrões e um repositório de serviços (nada de planilha Excel hein!)... Mas não ache que com isso você tem governança SOA, você só está um pouco organizado e assim que você tiver a oportunidade inicie um projeto sério de governança SOA.

Tirando a brincadeira acima, a resposta final é SIM, da para iniciar um projeto com  uma "governança mínima". A opção que não existe é "não ter nada de governança". 

Mas atenção: Se iniciar com uma governança mínima, tenha consciência que será necessário evoluir na governança em um futuro próximo (principalmente com a evolução do uso da abordagem SOA dentro da empresa).

PS: Geralmente, quando a empresa não tem budget e/ou tempo para a implantação da governança é que ao querer implantar SOA a empresa se preocupou muito mais com a compra de produtos e não deu o foco adequado para serviços. Por isso deve-se sempre escutar uma consultoria (vejam post Adotando BPM e/ou SOA - Parte 6).

Fabricantes e ferramentas fazem diferença na implementação de BPM e SOA?

Na minha opinião, ferramentas são itens de tecnologia. BPM e SOA são muito mais do que isso... Essas abordagens utilizam tecnologias, mas não são só tecnologias, por isso insisto quando me referencio a estas utilizando o termo “abordagens”. As vezes falar isso parece confuso, principalmente para quem é de TI, mas esse é o fato.

A escolha de ferramental vai muito mais de encontro com a arquitetura tecnológica de uma empresa (obviamente atendendo todos os requisitos), adequação com os usuários, sua infra, condições que o fabricante faz, suporte, entre outros motivos. Independente do que uma ferramenta é melhor ou pior que a outra, o diferencial é a equipe que vai implantar a abordagem. Há casos de sucesso e insucesso de implementações em Oracle, IBM, Microsoft, Red Hat, etc.

Mas o que faz a diferença na escolha de um ferramental então? Abaixo seguem algumas perguntas que não devem ficar sem uma boa resposta.

1. Qual é o road-map da plataforma?
2. Qual é a situação financeira do fabricante?
3. Qual é o investimento em P&D?
4. Qual é o tamanho da empresa (Brasil e exterior)
5. Quantos anos a empresa está no mercado (Brasil e exterior)?
6. Qual é o posicionamento do fabricante nos institutos de pesquisa (afinal, se alguém já fez estudos sérios porque você vai contrariar...)?
7. Qual é a quantidade de parceiros de negócios?
8. Qual é a quantidade de profissionais certificados na tecnologia?
9. O fabricante possui braço de serviços?
10. Possui agenda de treinamentos oficiais?
11. Possui suporte técnico local do fabricante 24X7 (você não vai querer ficar ligando para a Índia, por mais que passe por um telefone local né...)?
12. Possui suporte técnico do parceiro de implementação?
13. Quais são os casos de sucesso e conseqüentemente a maturidade?
14. A suíte oferecida é compatível com minha infra-estrutura (pense no passado, presente e futuro, por exemplo, atualmente você só tem máquinas UNIX... mas será que não haverá mudanças no futuro...)?
15. A utilização de padrões abertos é ampla?

É muito importante que em todas as fases de seleção das ferramentas e conseqüentemente do fabricante estes requisitos sejam observados com muito carinho, além da óbvia questão financeira.

Observação 1: Obviamente, a maioria das perguntas acima devem ser desmembradas em várias outras perguntas e distribuídas nas RFIs, RFPs, POCs, demos, entre outros passos da seleção de acordo com a metodologia da sua empresa ou utilizada pela consultoria.

Observação 2: Apesar de eu ter falado que ferramentas são itens de tecnologia não quer dizer que a suíte não influencie. Algumas suítes, com toda a certeza irão facilitar ou não a implantação. Nada de levar ao pé da letra... Olhando as perguntas você verá que várias direcionam para suítes e fabricantes de mercado com boa capacidade de implantação.

Adoção de SOA nas empresas (EUA e Europa)

Esta é um pesquisa feita no final de 2008 sobre a adoção de SOA em empresas dos Estados Unidos e Europa (que está publicada no The Forrester Wave™: North American SOA Systems Integrators, Q2 2009). Nunca vi um estudo completo sobre a adoção de SOA em empresas no Brasil ou América Latina (não quer dizer que não tenha, mas os que eu vi são mais baseados em enquetes do que em estudos profissionais)... Mas pelo meu sentimento, conversa com fornecedores, clientes e colegas de trabalho, acho que por aqui não está muito diferente.

Adoption Of SOA By North American And European Enterprises.

Fonte: Forrester, www.forrester.com

Most Distinguished Achievement Latin America 2009

Um pouquinho de auto-propaganda não faz mal a ninguém né...rs

Bem, aconteceu no final de outubro deste ano o evento mundial da IBM para a brand "Information Management" denominado IOD (Information On Demand). A Escala Informática foi a ganhadora do prêmio "Most Distinguished Achievement Latin America 2009". Para entender um pouco da importância deste prêmio, nesta brand de software estão alguns dos principais produtos da IBM, como: Cognos, Informix, DB2, InfoSphere DataStage, FileNet entre vários outos.

https://www-304.ibm.com/events/wwe/iod/iodbpawards09.nsf/$StaticContent/Winners

Entendendo Open Source

Gente, essa dica é quentíssima! Entrevista do "Maddog" para o programa Roda Viva da TV Cultura (19/10/2009). Se você quer realmente entender o que é Software Livre, seus benefícios, comercialização, entre outros pontos, vale muito apena assistir a esta entrevista.

Para quem não sabe, Jon “Maddog” Hal é um dos maiores gurus de software livre e presidente da Linux International. Sempre que ele fala algo é bom escutar, mesmo que você não seja um fã de software livre. Não se engane pensando que ele é um xiita...

Pena que algumas das pessoas que o entrevistaram não tinham mínima idéia do que estavam fazendo!

Para quem não assistiu ai vão os links no Youtube (está dividindo em 11 partes)

Parte 1, Parte 2, Parte 3, Parte 4, Parte 5, Parte 6,Parte 7, Parte 8, Parte 9, Parte 10,Parte 11

Fonte: TV Cultura, www.tvcultura.com.br

A verdade sobre a reutilização de serviços

A charge abaixo retrata muito do que acontece nas empresas quando estamos falando de reutilização de serviços (eu mesmo já presenciei este fato por diversas vezes). Este é um dos motivos que fazem com que a governança SOA seja fundamental para o sucesso da implementação desta abordagem.

Fonte: Geek & Poke, http://geekandpoke.typepad.com