Marco Mendes´s Blog

Hoje (19/04) está ocorrendo o MGJUG Tech Days, evento técnico organizado pelo grupo de usuário de Java de Minas Gerais (MG-JUG).

Apresentamos uma palestra neste evento, sobre integraçào de sistemas, arquitetura SOA e a plataforma Java. Esta palestra está disponível em anexo aqui para download.

Um termo que ganha cada vez mais momento nos noticiários de TI é o BPM. O BPM significa Business Process Management e pode mudar a forma com que a TI desenvolve sistemas. Mas, afinal, o que é o BPM?

Para entendermos o BPM, precisamos entender primeiramente como a TI desenvolve software hoje. Podemos resumir o processo da forma abaixo:

1. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado.

2. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

3. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

4. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente.

5. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

O ciclo acima, com pequenas variações, parece ser bem adequado. Muitas vezes, entretanto, o sistema colocado em produção não melhora a lucratividade ou outras metas de uma empresa. Isso ocorre porque a TI não tem fim em si mesma. A TI serve apenas a um propósito maior, que é fazer uma empresa funcionar mais eficientemente. A questão que se coloca é como uma empresa funciona com mais eficácia e eficiência.

A chave para esta resposta é com um processo de negócio mais adequado. Um processo de negócio é a descrição de um conjunto de procedimentos que envolve pessoas, tarefas, máquinas, softwares e outros elementos coordenados para atingir metas (objetivos) de negócio. Por exemplo, podemos ter uma meta em um banco de trazer 30M de reais em um ano através de novas contas. Isso pode ser realizado de várias formas, mas apenas os processos eficientes e eficazes podem implementar esta meta. Nesta hora o BPM entra em ação. O BPM é uma metodologia que permite que um especialista (ex: em operações bancárias) defina ou experimente diversos processos de negócio (ex: abertura de conta) e veja qual o mais efetivo.

O BPM pode ser feito apenas em papel, através de modelos e diagramas como os clássicos workflows. Entretanto, workflows não são modelos vivos e deixam muita margem para especulação ou incertezas.

O BPM pode ser feito através da geração de demandas para a TI para a construção de sistemas, experimentado hipóteses de negócios. Infelizmente, este processo é muito lento pois a construção de sistemas de informação é naturalmente demorada e o custo de readaptações nos sistemas é inviável.

Recentemente, o BPM ganhou força com ferramentas que permitem não somente expressar um processo de negócio através de seus componentes (pessoas, tarefas, máquinas, softwares), como também exprimir custos, tempo e consumo de recursos para cada um destes componentes. O analista de negócio pode então criar um simulacro do mundo real, desde que possua um profundo conhecimento do negócio (ex: abertura de contas bancárias). Além disso, algumas ferramentas podem literamente simular os diversos cenários propostos pelos analistas e gerar métricas de eficiência temporal ou monetária para o processo. Cenários podem ser comparados e o melhor cenário é passado para a TI para ser automatizado como um sistema de informação.

Exemplos de ferramentas que suportam estes modelos incluem:
- JBOSS jPBM (open-source)
- IBM WebSphere Business Modeler (Ferramenta mais robusta e profissional para BPM)

Modelos BPM podem ser expressos em linguagems vivas como o BPEL, que permitem a simulação de um workflows em um engine de simulação, presentes nas ferramentas acima. Modelos BPEL podem ser exportados como modelos UML para a TI ou mesmo ser incorporados em orquestradores de processo (ex: IBM WebSphere Process Server) para execução real.

A forma de trabalho da TI é diferente e pode ser então reescrita da seguintes forma:

1. O analista de negócio simula diversos processos de negócio para promover o alinhamento das metas organizacionais. Os melhores processos de negócio são escolhidos para automatização parcial (dado que componentes do processo de negócio envolvem seres humanos, como um correntista no processo de abertura de uma conta).

2. O analista de requisitos entrevista um conjunto de usuários para coletar suas necessidades para desenvolver uma visão sobre o sistema ser montado, que irá automatizar parte do processo de negócio.

3. Após uma série de entrevistas e reuniões, uma específicação de requisitos é produzida.

4. Em paralelo, o time de arquitetura técnica começa a trabalhar os requisitos suplementares do sistema (segurança ou desempenho, por exemplo) e trabalhar os riscos técnicos de um projeto através de testes preliminares. Uma arquitetura executável é produzida como resultado desta tarefa.

5. Ainda em paralelo, o time de arquitetura de negócio “coreografa’ o processo de negócio em uma ferramenta de orquestração. Cada elemento do processo de negócio será possivelmente automatizado como um ou mais serviços. (Por exemplo, a verificação de restrições bancárias em um sistema de abertura de contas pode ser implementada através de um ou mais serviços que consultam o Banco Central, CDL ou SERASA, por exemplo. Tecnicamente, estes serviços podem ser implementados em WebServices com o suporte de linguagens como Java ou C#).

6. Após uma fase de maturação dos requisitos, o sistema começa a ganhar corpo e é implementado e testado funcionalmente. O sistema agora não é mais uma peça monolítica, mas um conjunto de serviços (Web Services) que juntos formam workflows (processos de negócio derivados dos modelos BPEL dos analistas de negócios).

7. O sistema é colocado em ambiente de testes de homologação até que atinja estabilidade para ser colocado em produção.

Claramente, o sistema implementado agora estará alinhado com o negócio. Se o negócio mudar (e irá mudar), o ciclo é realizado em termos de manutenções evolutivas. Entretanto, esta dinâmica pode ser realizada de forma muito mais ágil que os antigos sistemas monolíticos pois o sistema é implementado como um conjunto de serviços, dirigido *por* workflows de negócio. Os serviços podem então ser re-arranjados muito mais facilmente para se adaptar às mudanças com menor custo.

Mais informações sobre BPM podem ser achadas aqui.
O padrão OASIS BPEL é descrito aqui

Middlewares de mensagens são mecanismos eficientes para integração de sistemas em plataformas complexas com robustez, tolerância a falhas e baixo acoplamento entre as partes. O conceito chave de middlewares de mensagens (MOMs) é o uso de processos normalmente assíncronos baseado na troca de mensagens entre as partes.

A apresentação em anexo (IntroducaoMensagens.pps) faz uma introdução a middlewares de mensagens no contexto dos problemas que estas tecnologias resolvem.

Compilo abaixo também um conjunto de recursos de apoio para saber mais sobre middlewares de mensagens.

Livros

Sites Primários

Dezembro próximo haverá um evento de SOA (Arquiteturas Orientadas por Serviço), organizado pelo IGPQ (International Quality and Productivity Center).

O evento contará com a presença de vários fornecedores de soluções como por exemplo a IBM, Oracle e BEA. Vários cases serão apresentados também, o que promete dar ao evento um bom momento técnico e permitir uma excelente coleta de oportunidades por interessados nesta nova filosofia de alinhamento de TI a processos de negócio.

A IBM possui uma plataforma aberta para desenvolvimento J2EE, chamada WebSphere Application Server (WAS CE). Este servidor é baseado no kernel do Apache Geronimo e adiciona ferramentas de maior usabilidade para a sua administração, assim como a geração de planos de implentação (Deployment Descriptors) compatíveis com as suas soluções de maior porte.

Os links abaixo são referências iniciais para entender o WAS CE e começar a produzir código Java EE que opere neste servidor.

Artigos:

Um plataforma de arquitetura de software é composta por diversos produtos, tais como servidores de aplicação, servidores de fila de mensagens, servidores de orquestração de processo BPEL, barramentos ESB, servidores de comércio eletrônico, portais e outros componentes.

Anexo neste blog uma apresentação sobre um plataforma robusta para arquiteturas de software - IBM WebSphere. Esta apresentação tem por objetivo exibir uma arquitetura de referência de plataformas de arquiteturas de software e exemplificá-la através da solução líder de mercado.

Arquivo em formato PPT: ArquiteturaReferencia_PlataformaWebSphere

A arquitetura SOA (Service Oriented Architecture) é um paradigma de engenharia de software cujo objetivo primário é permitir a integração de aplicações de TI com maior flexibilidade e suportar a criação e operacionalização de novos processos de negócio com mais rapidez e eficiência. Em termos simples, SOA implica em quebrar a visão de sistemas monolíticos e de manutenção muito complexa e, então, criar uma nova visão fragmentada através da exposição de uma camada de serviços, usualmente baseados em WebServices.

Grupos de prospecção e avaliação de tendências, como o Gartner Group e o Evans Data Corp, colocam cenários bem otimistas para o SOA:

“2005 will be the year of the SOA. Mark it down. According to The Yankee Group, 75% of firms plan to invest in the technology and staffing to enable a service-oriented architecture (SOA). Gartner, 2004
“Gartner Inc.’s prediction that by 2008, 60% of enterprises will use SOA as their ‘guiding
principle’ when creating applications and processes”, Gartner, 2004.
“In a survey of more than 1000 European developers, Evans Data Corp. found that nearly
75% are currently developing or are planning to develop SOA in 2005″, Evans, Jan 2005
Do ponto de vista de negócio, os principais objetivos de SOA são:

Melhorar a eficiência dos processos de negócio já existentes. A necessidade de automatizar aplicações B2B e B2C é uma tendência forte para a consolidação de eco-sistemas empresariais. Toda empresa hoje que deseje montar cadeias de fornecedores com produtos entregues Just-In-Time necessita de uma coordenação precisa de informações e acesso real-time a serviços de terceiros e de seus clientes.
Suportar a criação de novos processos de negócio. A criação de novos processos de negócio (inovação de negócios) é um diferencial nas empresas hoje. As áreas de TI precisam prover mecanimos que permitam que novos processos sejam rapidamente construídos e distribuídos.
Suportar a integração de sistemas legados em arquiteturas de serviços. Cada onda de evolução tecnológica trouxe novos paradigmas e aplicações, como por exemplo Mainframes, aplicações cliente servidor, ERPs, aplicações Web, aplicações J2EE/.NET, entre outras. As empresas de TI precisam disponibilizar toda a inteligência de negócio destes passivos de uma forma simples e que permita novas evoluções com custo reduzido.
Em uma ótica técnica, SOA envolve a integração de sistemas em um barramento compartilhado (Enterprise Service Bus) e a exposição de cada componente destes sistemas através de uma camada de serviços expostas como WebServices. A partir destes serviços, novos processos de negócio podem ser montados (orquestrados e coreografados) em linguagens como BPEL (Business Process Execution Language) e executados em servidores de aplicação dedicados a este propósito.

Para informações sobre este complexo e vasto tema, recomendamos os sites abaixo que disponibilizam um amplo acervo sobre arquiteturas orientadas por serviço, incluindo vídeos, apresentações e documentos diversos.