Category Archives: EAI

SOA, RFID e bagagens despachadas nas empresas aéreas

Posted on by • 0 comment
RFID-Architecture01.png
(fonte: SOASimples.com)

Alguns meses atrás, eu preparei a arquitetura simplificada acima para um trabalho no meu MBA no IBMEC São Paulo/INSPER. É apenas um exemplo de como uma arquitetura orientada a serviços (SOA) pode auxiliar em diversas aplicações de RFID. O objetivo foi apresentar uma solução para o rastreamento de cargas e bagagens aéreas utilizando tags RFID. Este tipo de solução já é utilizada em vários aeroportos e companhias aéreas no mundo. Veja um exemplo da United Airlines (Chicago, EUA) e da Air New Zealand (Nova Zelândia).

O Mercado mundial

A International Air Transport Association (IATA) estima que, por ano, as companhiam aéreas perdem US$ 3 a 4 bilhões/ano devido aos custos por extravio de bagagens. Em um cenário de pressão por redução de custos nas passagens, concorrência acirrada, reclamação dos clientes das longas filas nos balcões de check-in, eficiência operacional etc, fica claro que alguma ação precisa ser tomada para diminuir estes custos. É um investimento perdido e, pior, com “retorno negativo”, porque além dos problemas causados aos passageiros que tiveram sua bagagem extraviada, as empresas correm o risco de não ver nunca mais aquele passageiro em seus aviões.

Números, números…:

  • IATA estima que quase 33 milhões de malas são extraviadas todo ano
  • Este número representa algo próximo a 1.4% de todas as bagagens
  • Custo médio por bagagem extraviada: $100

A presão por redução de custos operacionais é tão grande que lá fora as empresas cobram de US$ 15 a US$ 100 adicionais simplesmente para despachar a bagagem dos seus clientes. Se esta moda pega por aqui…

Uma das soluções pode ser a utilização de RFID. Na minha opinião os custos iniciais podem até serem relativamente altos, porém os ganhos em eficiência, confiabilidade e até mesmo retenção de clientes são enormes. Você volta a utilizar os serviços de uma companhia aérea se, frequentemente, sua bagagem é extraviada? Pouco provável, certo?

Importante: não se trata apenas de imprimir tags RFID e colocar nas bagagens (sim, hoje temos impressoras que imprimem as etiquetas de RFID). Existe todo um ambiente de sistemas tais como ERP, CRM, despacho de bagagens, que precisam ser integrados e em tempo real.

As tecnologias e decisões de arquitetura para estas situações envolvem o uso de:

Não se assuste com a “sopa de letras” acima. Todas as tecnologias são correlatas, se complementam para a construção de um “meio-ambiente” que permita operar de forma eficiente uma solução baseada em eventos.

Investimentos: o case da Air Zealand

KioskRFID-AirZealand.jpg



A Air Zealand foi além do simples controle. Ela implantou kiosks (vide foto acima) onde os passageiros despacham suas bagagens devidamente identificada com tags RFID.

O investimento foi US$ 16.5 milhões. Com este valor a empresa:

  • instalou 112 kiosks como este e
  • mais 84 gate scanners que são os “leitores” de etiquetas dispostos em vários locais por onde é realizado o transporte e triagem das bagagens
  • tudo isto foi implantado em 26 aeroportos onde a empresa opera

Com isto ela foi a 1a. companhia aérea a oferecer RFID-enabled self-scanned check-in. Você prefere isto ou enfrentar a fila nos balcões? Isto influenciaria a escolha da sua companhia aérea? Quanto tempo você economizaria?

Como SOA ajuda

A questão central é o controle mais eficiente das bagagens e cargas, agilidade, integração dos vários sistemas, e uma grande redução de custos. Todos ganham no processo, a companhia aérea, a empresa que administra os aeroportos mas, principalmente, o cliente.

Existem middlewares utilizados em arquitetura SOA que são específicos para tratar centenas de milhares de eventos como estes gerados por etiquetas RFID. SOA é uma abordagem ideal para tratar de eventos complexos e integração de ambientes heterogêneos, com custo relativamente baixo, sem necessidade de reescrever o legado. Por tudo isto SOA é uma excelente escolha.

No próximo post vou tratar dos middlewares que são específicos para tratamento de CEP em uma arquitetura SOA. Não perca!

Category: Architecture, CEP SOA, EAI, ESB, inovation, RFID, SOA, Uncategorized

JBoss Libera HornetQ: open-source messaging system

Posted on by 1 comment

Se você é familiar com os produtos da JBoss/Red Hat, já deve ter ouvido falar do JBoss Messaging (v 1.x). Como o nome diz é um middleware orientado a mensagens (ou MoM – Message-oriented Middleware), que era a solução de mensageria padrão do JBoss Enterprise Application Platform, JBoss SOA Platform e JBoss Application Server version 5.0.

O produto evoluiu e a versão 2.x ficou tão diferente do projeto original que eles decidiram dar um novo  nome para o produto: HornetQ.

Principais características

  • como o projeto original do qual é originado, o HornetQ é open-source (Apache v 2.0 licence)
  • roda em qualquer plataforma Java 5.x ou superior
  • suporta JMS 1.1 API, apesar de ter uma API de mensagens proprietárias (que a JBoss alega que tem uma performance superior)
  • provê sistema de mensagens persistentes com performance de MoM que trabalha com mensagens não persistentes (em memória)
  • pode ser integrado com o JBoss Application Server ou com com outro Java server/container
  • pode ser “empacotado”(embed) em sua própria aplicação (!)
  • opção de alta disponibilidade (server replication e client failover)
  • permite a criação de clusters (load balance, distribuição geográfica dos seus MoMs etc)
  • “core” do produto baseado em Plain Old Java Objects (POJO)
  • etc..

Arquitetura (high-level view)

Documentação

  • Guia rápido (PDF), recomendo!
  • Manual do Usuário (PDF)

MoM – Definição

Por fim, mas não menos importante, vamos a uma definição básica de um Message-oriented middleware (MOM).

Basicamente é uma solução de infraestrutura de software que recebe e envia mensagens. A arquitetura destas soluções tem um grande foco em questões relacionadadas a confiabilidade da entrega/envio das mensagens, interoperabilidade (“conversam” com vários protocolos) e portabilidade (ambientes altamente heterogêneos).

Na minha opinião, do ponto de vista de arquitetura de software, são soluções “elegantes” que reduzem a dependência e a complexidade das suas aplicações e/ou componentes. Como arquiteto(a), por exemplo, você não precisa se preocupar como uma mensagem vai sair do ambiente mainframe, ser persistida, transformada e roteada para, finalmente, ser entregue no formato de um SMS para seu cliente. Isto permite que você mantenha o foco no desenho, na arquitetura da solução, que é o mais importante.

Tudo indica que Mensageria será um dos elementos-chave em Cloud Computing. A JBoss sabe disto e lançou o HornetQ com este objetivo ambicioso: ser o provedor de mensagens preferido no ambiente de cloud computing.

Boa sorte!

Category: Architecture, Cloud Computing, EAI, lightweight, open-source, REST, SOA | Tags:

BI, SOA e Integração de Dados em Tempo Real

Posted on by • 0 comment

Uma discussão recorrente no mundo da arquitetura orientada a  serviços (SOA) é como o Business Intelligence (BI) se integra neste cenário e, no caso da empresa onde trabalho (operadora telecom), como disponibilizar dados em tempo real para o BI.

Antes de mais nada sabemos que o Business Intelligence não tem a premissa de tratar dados em tempo real. Utilizamos para consolidar dados de várias fontes, gerar gráficos e relatórios para os vários níveis da empresa (operacional, tático e estratégico), como um dashboard para os tomadores de decisão etc, mas quase nunca como uma ferramenta de análise de dados em real time.

BI

Falando em BI, em uma pesquisa realizada alguns anos atrás, mostrou os principais motivadores que levavam as empresas a adotar esta solução:

  • Aumentar a satisfação e a retenção de clientes: 62%
  • Dimunição de Custos: 53%
  • Aumento de Receita: 48%
  • Aumento de Lucratividade: 41%
  • Aumento de Market-share: 37%
  • Ferramenta de redirecionamento de produto: 30%

(fonte: http://www.information-management.com/issues/20040201/8034-1.html)

Análise de Dados em Tempo Real

Soluções do tipo BAM (Business Activity Monitoring), e mesmo os já conhecidos BI, podem demandar a apresentação de dados e gráficos de dados com uma latência menor. Alguns exemplos simples: vendas realizadas na última hora, ligações telefônicas completadas com sucesso nos últimos 45 minutos, lotes produzidos nas últimas 2 horas, transações com cartão de crédito no últimos 5 minutos etc.

Se o volume for considerável, milhões de transação no caso de uma operadora de telecom ou de cartão de crédito, é um desafio disponibilizar estas informações através do BI ou BAM. Não apenas estes dois mercados, mas todas as operações onde temos eventos em real-time que precisam ser capturados, correlacionados e apresentados para monitoramento em tempo real.

Estes cenários são típicos de Complex Event Processing (CEP) e Event-driven Architecture (EDA). Detalhes adicionais neste link.

Oracle e Integração de Dados em Tempo Real

Ontem (23/Jul/2009) a Oracle anunciou a compra da GoldenGate, uma empresa de San Francisco, Califórnia, que possui uma solução de integração de dados em tempo real. Veja a imagem abaixo que consta na apresentação oficial da Oracle:

Verifique que a solução da GoldenGate alega que extrai e disponibiliza os dados em “tempo real” para vários “consumidores”, entre eles: Message Bus típicos de arquitetura SOA/EDA e o que eles denominam “Operational BI“.

Veja uma arquitetura simplificada de onde como a solução da GoldenGate disponibiliza dados em tempo real para ferramentas de análise e BI:

A apresentação detalha ainda alguns cases de sucesso da implantação solução da empresa de San Francisco. Mesmo sendo um material com viés promocional de como os produtos da Oracle serão integrados com o da GoldenGate, a leitura vale a pena.

Category: Architecture, CEP SOA, EAI, EDA, ESB, middleware, monitoring, Oracle, SOA

Open-source SOA nas Empresas (by FUSE/Progress)

Posted on by • 0 comment

IONA é subsidiária da Progress Software que “empacota” os produtos da Apache e disponibiliza um conjunto de soluções open-source para arquitetura orientada a serviços (SOA).

Algumas semanas atrás (Outubro/2008) eles disponibilizaram um PDF com o título “Como Utilizar Open Source SOA de forma Segura nas Empresas” (10 pags). É necessário registro (gratuito) no site da InfoQ.com (o que eu recomendo fortemente devido à qualidade dos artigos do tipo “de desenvolvedor para desenvolvedor”).

Bom, vencida a via crucis do registro você pode baixar o documento da IONA e ter maiores detalhes do conjunto de soluções “empacotadas” com a marca “FUSE”:

  • FUSE ESB – baseado no Apache ServiceMix. Suporta a especificação JBI (JSR 208)
  • FUSE Message Broker – baseado no Apache ActiveMQ
  • FUSE Services Framework – baseado no Apache CXF. Desenvolvedores Java podem utilizar JAX-WS, JavaScript, REST ou POJOs para criar web services
  • FUSE Mediation Router – baseda no Apache Camel
  • FUSE Integration Designer – ferramenta de desenvolvimento baseada no Eclipse com algumas funcionalidades adicionais para a suite SOA da IONA

Em http://fusesource.com/ você pode fazer o download, testar, ler a documentação, ter acesso ao Wiki, F.A.Q, whitepapers, vídeos com passo-a-passo de implementações etc.

Clique na imagem abaixo e veja um destes vídeos que mostra como uma EIP (Enterprise Integration Pattern) é criado.

EIP at Eclipse

EIP at Eclipse

Category: EAI, ESB, esb open-source, middleware, open-source, Progress, soa-opensource, vendors

Por que Serviços não devem se comunicar diretamente?

Posted on by • 0 comment

Nos vários eventos e discussões sobre SOA que participamos nestes últimos 03 anos, inevitavelmente, éramos apresentados a cases reais de implementação de arquitetura orientada a serviços que não passavam de um conjunto de Web Services.

Este “erro” é tão comum que existe até um termo em inglês para designar esta arquitetura que “pretende” ser SOA: JBOWS (Just a Bunch of Web Services, ou apenas uma porção de Web Services). Este termo foi definido pelo Joe McKendrick ainda em 2005 (!).

Muitos arquitetos de integração estão implementando JBOWS, Web Services Integration (WSI) ou qualquer outra coisa e “juram de pés juntos” que isto é SOA. Não é!

Desde que Ronald Schmelzer escreveu um artigo com o título “Why Service Consumers and Service Providers Should Never Directly Communicate“, esta polêmica aumentou e provocou uma boa discussão na blogosfera.

Afinal, por que Service Consumer não deve ser comunicar diretamente com Service Provider?

Por várias razões mas, basicamente porque seu ambiente SOA deve pressupor um ambiente heterogêneo, sujeito a mudanças e com “baixo acoplamento”:

  1. Baixo acoplamento na Implementação
  2. Baixo acoplamento no “Contrato” de Serviço
  3. Baixo acoplamento na “Política” de Serviço
  4. Baixo acoplamento no Processo
  5. Baixo acoplamento no Schema de Dados
  6. Baixo acoplamento na Infraestrutura
  7. Baixo acoplamento na “Camada” Semântica

Sobre este assunto recomendo este artigo: “The Seven Layers of Loose Coupling” (também no site Zapthink.com).

Qual a Solução? Resposta: “Late-Biding”!

Late-biding significa basicamente que um cliente não está ciente (aware) do seu endpoint (service ou server). Um cliente faria uma requisição a um IP virtual e um “proxy” (também chamado de application delivery controller) verifica o cabeçalho HTTP para determinar o endpoint apropriado . O termo “late” (atrasado) é utilizado porque a decisão de direcionar ao endpoint só é tomada após a requisição do cliente.

  1. Cliente envia uma requisição para o application delivery controller
  2. O application delivery controller verifica a requisição e determina o endpoint (server ou pool)
  3. O application delivery controller direciona a requisição para o endpoint (server ou pool)

No mundo real uma das formas de implementar o late binding é através do uso do WSDL (Web Services Description Language).

  1. Cliente requisita o WSDL apropriado, opcionalmente de um registry
  2. Cliente determina o endpoint através de um parsing no WSDL
  3. Cliente direciona a requisição para o endpoint definido no passo anterior

Mais detalhes aqui.

Conclusão

O “Late-binding” não é a solução para tudo. Existem outras abordagens e em cada cenário devem ser avaliados os prós e contras. Este é um trabalho do arquiteto de integração mas, certamente você deve, sempre que possível, ter em mente os 7 níveis de abstração em seu ambiente SOA e o bom senso para fazer o trade-off correto.

Uma crítica interessante e cuja leitura também recomendo está neste post do blog da Anne Thomas Manes (Burton Group).

Boa sorte!

Category: Architecture, EAI, SOA, web-service

SOA e Data Integration

Posted on by • 0 comment

Comecemos pelo básico.

O que é Data Integration?

ETL from Wikipediaa) Novo nome que os vendors deram para ETL

b) Processo que combina dados de várias fontes e entrega para o usuário uma visão unificada destes dados (by Wikipedia)

c) Organizar e reconciliar dados dispesos em sistemas heterogêneos e disponibilizar os mesmos para análise

d) Todas as opções acima (correto!, opção “d”)

Como fica a Integração de Dados em um ambiente SOA

Em 2006 estávamos na fase final de definição da solução de software que seria a base da nossa arquitetura SOA. Recebemos a visita de alguns fornecedores que afirmavam que tinham produtos de integração de dados “SOA compliant“.

O cenário abaixo ilustra de forma simplificada o nosso dilema. Temos o vários sistemas A, B e C, legados ou não; temos os bancos de dados corporativo, e também várias outras fontes de dados: arquivos texto, bases de dados departamentais, planilhas etc. Como todos estes dados irão se integrar em nosso ambiente SOA?

Este é um ambiente típico de qualquer empresa e, se estiver pensando em SOA (como mostrado na figura acima), você precisa achar uma alternativa para integrar todos estes dados.

Qual o problema com as ferramentas de Integração de Dados?

O maior problema é que é estas ferramentas, diferente de uma solução baseada em SOA, não suportam movimentação de dados em tempo real. Vamos dar um exemplo simples:

  • o sistema A é uma aplicação antiga (leia-se “legada”) que o seu call-center utiliza para informar aos clientes (tempo real!), por exemplo, o saldo de seu telefone pré-pago
  • Quando o cliente finaliza uma ligação a plataforma de pré-pago (qualquer que seja ela) atualiza automaticamente/imediatamente o saldo
  • Em seguida o cliente liga para a central de atendimento e deseja saber o saldo atual

Pergunta: seu cliente pode esperar até que o próximo ETL (que ocorre uma vez por dia, certo?!) ou você deve garantir que no momento da consulta o sistema A “dispare” uma consulta (tempo real!) à plataforma do seu serviço de pré-pago, que retorna o saldo daquele cliente? Tudo isto deve ocorrer neste tempo:

- (cliente) “Gostaria de saber meu saldo!”
- (atendente) “Certamente senhora. Você poderia me informar o número do seu telefone?”
- (cliente) “É 99-9999-9999″
- (atendente) “Um momento senhora…”
- (Sistema A) Consulta base do sistemas, recupera e exibe os dados do cliente, ao mesmo tempo em que dispara um processo/serviço que consulta o saldo na plataforma de pré-pago
- (atendente) “Seu saldo atual é R$ 50,0. Posso ajuda-la em algo mais?”
- (cliente) “Não, muito obrigada”

Conclusão

As ferramentas de Integração tem suas qualidades e podem solucionar outros problemas das empresas que precisam, por exemplo, consolidar e movimentar grandes volumes de dados (entre outras funcionalidades).

Uma excelente alternativa é utilizar Web Services para recuperar os dados à medida que os sistemas requeiram estas informações. Claro que existem várias outras questões que devem ser consideradas e o objetivo deste post não é resolver este grande dilema, porém existem soluções simples para um cenário tão comum quanto o descrito acima. Veja a figura abaixo que ilustra esta alternativa:

Category: Architecture, BI, EAI, SOA

SOA e Enterprise Architecture (EA)

Posted on by • 0 comment

SOA LegoQual a relação entre SOA, Enterprise Architecture (EA) e Reference Architecture (RA)?

Neste post do blog de Suchin Rengan’s achei uma resposta simples para esta questão:

  • Enterprise Architecture (EA) é uma representação dos processos do core business e entidades e a forma como eles se relacionam. De certo modo é uma abstração do modelo de negócios de uma organização que descreve o estágio atual e futuro. EA tem o foco no alinhamento de TI com os processos do core business e suas entidades relacionadas
  • SOA é uma abstração de como a EA é apresentada para a organização na forma de serviços. É uma arquitetura que é orientada em torno de Serviços. SOA pode ser applicada para EA onde os processos do core business são “abstraídos” e disponibilizado para a organização como Serviços. Então SOA não é EA, mas pode ser aplicada em uma EA
  • Reference Architecture (RA) é um blueprint de como SOA é conceitualizada na forma de Serviços e suas composições. Deve servir de guia para as organizações na criação e na “montagem” de categorias de serviços e seus mecanismos de acesso

Interessado no assunto? Leia também este post de Joe McKendrick: “SOA, Enterprise Architecture, BPM all the same underneath“.

Category: Architecture, EAI, SOA

COBOL e SOA

Posted on by • 0 comment

Claro que a imagem aí do lado (tirada de um site sobre COBOL) é apenas para provocar.

COBOL ainda é uma linguagem muito utilizada, principalmente no mundo financeiro. De acordo com este post, existe uma estimativa da IBM/Rational que temos hoje aproximadamente 200 Bilhões (!) de linhas de código em COBOL. Com certeza, é algo que não deve ser ignorado pela industria de software.

E é esta industria, ainda de acordo com a notícia acima, que está empenhada em “modernizar” o COBOL através de SOA. Cada um com sua abordagen, IBM, Oracle, HP e Intel apresentam suas “armas” para desafio.

A IBM acredita (claro) que o mainframe é uma peça importante e vai se encaixar no lego de SOA.

Entretanto, HP, Intel e Oracle, se juntaram em uma iniciativa (AMI*) que, em linhas gerais, propõe substituir a parte “crítica” os sistemas em COBOL por serviços e novas implementações mais aderentes à proposta de arquitetura orientada a serviços.


(*AMI = Application Modernization Initiative)

Claro que o objetivo é trazer para servidores HP, com processadores Intel e utilizando o middleware Oracle Fusion, alguns milhões destas linhas de código escritas em COBOL.

Como diria um amigo meu, quem acha que esta linguagem está morta vai ter a nota fiscal do caixão impressa em um programa COBOL!

Category: EAI

SOA e Integração Dados (Open Source!)

Posted on by • 0 comment

A maioria das organizações se deparam com um problema de manipular vários tipos de arquivos, de várias fontes (internas e externas à empresa). Lidar com todos estes dados, com vários formatos, de diferentes origens exige um grande esforço da equipe de TI:

Alguns estudos indicam que a implementação do acesso e manuseio de tipos de dados complexos, consomem até 70% do esforço de implementação de aplicações ou serviços

É muito tempo para qualquer projeto/implementação. Data Integration, Data Abstraction e Data Services são pontos básicos em um contexto de uma arquitetura SOA. Não apenas porque a preservação do legado é importante e um motivador importante para esta arquitetura mas, principalmente, porque é uma solução de arquitetura necessária quando temos uma realidade como a atual em que nossos sistemas precisam interoperar com mais e mais sistemas externos e internos.


E se esta solução for Open Source? Melhor ainda. Veja a seguir um pequeno resumo que eu fiz a partir da solução da XAware v.5.

1. Motivadores

  • Algumas industrias (e.g. Telecom, Finanças) lidam com várias fontes de dados, de várias origens e precisam manipular, transformar e garantir que seus processos de negócios sejam corretamente “alimentados”
  • Interoperação de forma “transparente” para o negócio, sistemas internos e sistemas de terceiros (parceiro, governo etc)
  • Arquitetura aderente a SOA

2. Definição de Data Service Layer (DSL)/Data Service

De forma bem simples, Data Service Layer (DSL) ou simplesmente Data Service é uma camada que abstrai, para o Business Process, a fonte do dado e vice-versa. É uma solução de Arquitetura, um middleware, que isola as fontes de dados dos consumidores (Web Services, Business Process etc).


Acima vemos a integração de dados (Data Integration) sem e com DSL. Fonte: este excelente artigo de Mark Davydov no IBM DeveloperWorks website.

3. SOA sem DSL?

Claro, mas com vários riscos. Exemplo: “acoplar” os seus serviços diretamente nos bancos de dados do legado. Possíveis problemas:

- Altamente dependente do schema do banco; quem tem controle das mudanças? quem irá avisar os arquitetos das mudanças? como avaliar o impacto?

- Dependência da forma de conexão para recuperar os dados

- Bases de dados relacionais de típicos Sistemas de Informação não garantem que os dados estarão em um “estado lógico” que é esperado pelo seu Business Process. Não por “culpa” do banco ou do sistema mas, simplesmente, porque não é função destes participantes garantir a integridade lógica de uma informação para o processo de negócios


4. Vantagens
Aqui eu cito o documento que deu origem a este post. Um artigo da ZapThink.com, escrito por Jason Bloomberg (necessário cadastro, gratuito, para baixar o PDF completo). Vale a pena a leitura.

  • The ability to remap existing physical schemas into virtual schemas that are better logical representations of the data for SOA. Thus, the developers who build Services simply refer to a logical data layer that will be bound to back-end physical data.
  • The ability to combine many schemas into a common virtual schema, which allows avirtualization greatly simplifies the use of the data in the context of SOA since the SOA implementation leverages a single common schema multitude of very different databases and schemas to appear as one. This
  • The ability to place schema volatility into a single configurable domain. As physical and logical semantics, and thus schemas change, the architect can adjust for those changes with a single configuration layer, providing better agility since changes to schemas don’t inherently mean redevelopment of the Services

5. XAware 5.x

É a solução open source citada no artigo acima que se propõe a realizar esta integração tão necessária em um ambiente SOA.

Category: EAI, SOA

Array