Coincidência ou não, a sigla do projeto confunde-se com a sigla do Distúrbio de Déficit de Atenção, que é um transtorno neurobiológico, ou seja, não tem relação alguma com o assunto deste post.

Mas voltando ao débito direto autorizado. A idéia é muito boa, onde o DDA é mais um sistema que promete facilitar a forma de emissão de compromissos de pagamentos. Hoje, os boletos ou títulos são emitidos em papel pelos bancos cedentes que os enviam aos clientes (devedores), que por sua vez escolhem a instituição de pagamento.

Com o novo sistema, os bancos cedentes verificam se o cliente (devedor) está cadastrado no débito direto autorizado, geram o boleto ou título eletrônico e enviam ao DDA, que armazena as faturas eletrônicas. O banco do cliente (devedor) consulta no DDA esses títulos eletrônicos e os disponibilizam nos seus canais eletrônicos. Com isso, o cliente devedor pode utilizar qualquer um desses canais disponibilizados no seu banco para realizar o pagamento do boleto ou título eletrônico.

Os benefícios são clichês: agilidade, conveniência, eficiência para o mercado, integração, solução de vanguarda, segurança, menos filas nas agências. Porém, um dos benefícios merece destaque que é a redução de papel, como a transação é eletrônica, não iremos mais receber aqueles boletos indesejados que colocamos sob o imã da geladeira para não se esquecer do compromisso. O portal de notícias InfoMoney publicou ontem (29/12) uma matéria, onde dizia que “a expectativa da Febraban (Federação Brasileira de Bancos) é de diminuir em 50% a emissão de boletos impressos em três anos.”

Esta matéria do InfoMoney também destaca os investimentos em TI que esse novo sistema de pagamentos demandará, principalmente em servidores e storage, pelas instituições participantes do projeto, neste caso os próprios bancos.

Além disso, na minha visão, uma arquitetura orientada a serviços serve como uma “luva” para a solução do DDA. Particularmente não tenho qualquer informação técnica sobre este projeto. Algum leitor deste blog conhece algum detalhe que poderia compartilhar conosco?

A Febraban possui um site com mais alguns detalhes sobre o projeto DDA. Quem tiver interesse é só acessar: www.febraban.org.br/projetodda

No mais, feliz 2009 a todos os leitores do blog. Obrigado a todos que também contribuíram e ajudaram em 2008 a construir este espaço de propagação de conhecimento. Até 2009!!!

[]’s

Fábio Rosato

Related posts:

1. SOA ainda não é uma realidade nos bancos brasileiros, diz IDC
2. Você tem uma referência?
3. Projeto de serviços: contratos, camadas e EDA.

Contratos e interfaces

Podemos considerar serviços como interfaces que definem uma topologia corporativa. Alguns autores enfatizam que é possível definir SOA como “Arquitetura Orientada a Interfaces”, mas com um foco corporativo, não no contexto de uma única aplicação. Desenvolver para interfaces traz grandes benefícios.

Uma interface encapsula um determinado backend e deve ser projetada como um contrato, um acordo entre consumidor e fornecedor. De forma que, se o cliente cumprir sua parte (pré-condições), o serviço garante o resultado especificado (pós-condições) com algumas exceções também especificadas. Caso o cliente não garanta a sua parte no acordo, o serviço tem seu comportamento comprometido de forma imprevisível.

Pré-condições: são os parâmetros de entrada e os estados do sistema que devem ser validados antes da “execução” do serviço.

Pós-condições: especificação do estado do sistema (por exemplo, objetos criados ou destruídos, atributos e relacionamentos alterados) ou os parâmetros de saídas garantidos/válidos após a “execução” do serviço. Em outras palavras, o resultado esperado da “execução” do serviço.

Exceções: todas as situações em que a “pós-condição” não pode ser garantida, mesmo com a “pré-condição” atendida.

As definições de “pós-condições”, “pré-condições” e “exceções” não devem ter um caráter de documentação. A atitude mental deve ser de projetar um contrato que proporcione a maior coesão possível, obtida com refinamentos sucessivos (durante todo o ciclo de vida do serviço o contrato deve ser considerado e evoluído), pois todas as decisões neste âmbito terão conseqüências diretas na arquitetura corporativa.

No contrato é especificado onde ficará a lógica, evitando, sobretudo, redundância e falta de coesão. Se uma determinada lógica estiver coesa com o serviço (normalmente a lógica utiliza somente os dados encapsulados no serviço), ela é implementada no próprio serviço, “disparando” possíveis exceções. Caso contrário, o cliente implementaria ou delegaria a lógica (cumprindo as pré-condições) para garantir a execução e obter o resultado esperado. Portanto, a lógica nunca dever ser duplicada no serviço e no cliente.

Alterações devem respeitar o contrato. Em uma alteração do contrato, ou seja, alteração da interface de um serviço, todos os seus clientes devem ser revistos. Interfaces publicadas devem ser bem projetadas, para garantir mudanças de forma controlada. Testes automatizados para garantir o contrato também são importantes, tornando alterações viáveis.

Serviços encapsulam os dados de seu backend - essa é uma questão essencial. Caso um determinado cliente esteja utilizando dados obtidos por intermédio de um serviço para a “execução” de uma regra de negócio, provavelmente essa regra ficaria mais coesa no serviço, não no cliente, ou seja, o serviço deveria fornecer uma operação que encapsula a regra, retornando, por exemplo, um boolean, evitando desta forma que o cliente receba dados desnecessários.

Seguindo o mesmo princípio, um serviço não deve receber dados de outros serviços para cumprir uma regra de negócio. Normalmente, tudo o que recebem são seus próprios dados ou, no máximo, identificadores únicos de conceitos de outros serviços, nunca dados/objetos que não estejam coesos.

Eventualmente, temos regras de negócio que não pertencem exclusivamente a um serviço (utilizam dados/objetos de vários serviços). Neste caso, um serviço composto pode oferecer uma pequena camada de código que orquestra dois ou mais serviços, a fim de cumprir a regra. O serviço composto seqüencia as operações de outros serviços mais básicos, criando uma indireção.

Serviços encapsulam seus dados, por isso, sempre achei estranhas as abordagens de BI com SOA. BI consolida dados, para isso, consomem dados; serviços seguem o caminho oposto, escondem dados. Ainda temos questões de desempenho envolvidas pela característica distributiva dos serviços. No entanto, um interessante artigo da InfoQ, mostra que SOA com EDA pode, em muitos casos, substituir abordagens ETL para consolidar bases, com vantagens, para apoiar iniciativas de BI. EDA é um tema pouco explorado, mas que merece muito mais atenção do que tem recebido no Brasil. EDA usa mensagens assíncronas e promove baixo acoplamento de forma muito interessante; favorece, também, abordagem com BAM e CEP.

Camadas e serviços

A identificação de serviços é uma tarefa importante. As operações de um serviço devem estar coesas com seus dados e com sua interface. Além disso, os serviços devem fazer sentido para o negócio. Neste artigo, existem alguns tipos de serviços básicos definidos por Thomas Erl.

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.

Pode-se citar como exemplo aplicações que são divididas em camadas (apresentação, aplicação, negócios, infra-estrutura), possibilitando que as alterações sejam contidas. Dessa forma, alterações simples na apresentação ou na persistência não obrigam que quase todo o sistema seja alterado como conseqüência direta.

A abordagem com camadas possui regras simples. A camada mais alta usa vários serviços definidos pela camada mais baixa, mas a camada mais baixa ignora a existência da camada mais alta. Além disso, cada camada normalmente esconde suas camadas mais baixas, conceito conhecido como “camada opaca”; mas também são possíveis “camadas transparentes”, conforme a figura abaixo.

Thomas Erl define algumas camadas básicas para SOA (são possíveis abordagens mais elaboradas com mais camadas, por exemplo, uma camada para serviços de entidades compostos e outra para serviços básicos), na figura abaixo.

No caso de serviços básicos, que encapsulam diretamente o domínio (serviços de entidade, por exemplo), é interessante também que sejam controladas as trocas de mensagens de diretas na mesma camada. Neste caso, podemos usar uma camada superior como indireção, orquestrando serviços da camada inferior. Com essa abordagem, temos um controle da dependência de forma mais simples possível. Apesar de sua característica “procedural”, essa abordagem evita dependências cíclicas. No geral, não existem respostas fácies, pois existem muitas outras variáveis como, por exemplo, desempenho, cada caso deve ser avaliado.

Event-driven architecture

Conforme mencionado anteriormente, abordagens EDA promovem um grande desacoplamento. EDA não é apenas uma questão arquitetural, pois eventos são encontrados no negócio. Um evento pode ser qualquer alteração de estado do negócio. Essa abordagem deve ser seriamente considerada em todos sistemas em uma estratégia SOA.

Normalmente, um sistema que origina o evento envia uma mensagem para uma ferramenta ESB, por exemplo. A ferramenta notifica todos os serviços que assinaram o evento , alterando o fluxo mais comum de uma abordagem SOA ( request-and-reply pattern ) para uma abordagem “inversa” ( publish-and-subscribe pattern). Em certos cenários são possíveis combinações das abordagens.

Fluxo mais comum de uma abordagem SOA:

Event Driven Architecture:

Related posts:

1. Anatomia do serviço. O que é, afinal?
2. Anatomia do Serviço - Parte 2
3. Anatomia do Serviço - Parte 1

Fui convidado para fazer uma apresentação no primeiro dia. O tema será: “Governança de serviços e qualidade arquitetural em SOA”. Discutiremos sobre controle de qualidade de mecanismos arquiteturais e gestão de serviços. A idéia é ressaltar os cuidados essenciais com qualidade em uma Arquitetura Orientada a Serviço, e traçar um paralelo entre Qualidade x Reúso x Governança SOA, com conceitos, alguns exemplos práticos de cases e ferramentas.

Mais detalhes, alguns links abaixo:

• Programação (lista de palestras e empresas)
• Site da ASR Consultoria
• Blog do Robson

[]s
Marcílio

Related posts:

1. SOA na Prática [vídeo]
2. SOA - Erros comuns
3. Você tem uma referência?

O SOA Self Assessment é uma das práticas mais aplicadas para avaliação do nível de maturidade e elaboração de um roadmap próprio de implantação de SOA.

Diversos fornecedores disponibilizam Self Assessments através questionários com feedbacks automáticos. É bastante interessante. Outros oferecem assessments presenciais apenas, que, na minha opinião, é o que funciona de verdade!

Embora um bom SOA Assessment deva ser realizado avaliando características de negócio e arquiteturais não tão “objetivas”, é sempre bom dar uma zapeada pelos Self Assessments automáticos disponibilizados na web. Alguns exemplos:

• HP SOA Maturity Assessment.
• IBM SOA Self Assessment. 
• SoftwareAG SOA Technology Assessment.
• JBoss SOA Assessment.

Estes assessments já estão disponibilizados há um bom tempo (alguns há muito tempo até), mas algumas pessoas já me perguntaram sobre isso… e como ainda não havia nada no blog falando a respeito, fica aí a referência.

Obs: Só tome cuidado, é um diagnóstico rápido e superficial! Não o use como norte para sair por aí comprando

[]s
Marcílio

Related posts:

1. Certificação SOA - SOA School
2. Evolução de Componentes e Serviços
3. SOA na realidade atual

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.

Related posts:

1. Adoção de SOA
2. WS-* Parte 1
3. O que é SOA?

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.”

Related posts:

1. Conferência da Qualidade de Sofware
2. SOA - Erros comuns
3. Adotar SOA é mais complexo do que parece

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.

Related posts:

1. Anatomia do Serviço - Parte 2
2. Anatomia do Serviço - Parte 1
3. Projeto de serviços: contratos, camadas e EDA.

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

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.

Related posts:

1. Reutilização de software na China?
2. Com crise, organizações adiam investimentos em SOA
3. Sete dicas para Governança SOA

Related posts:

1. Adoção de SOA
2. SOA ainda não é uma realidade nos bancos brasileiros, diz IDC
3. SOA na realidade atual

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

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.

Related posts:

1. Para Software AG, SOA e BPM têm grande oportunidade com a crise
2. Outros eventos SOA no mundo!
3. Adoção de SOA