Embed Size (px)
Citation preview
Introdução
Solução na TI a cada dia se torna uma só
referência de integração e reuso. Essa palavra
REUSO você deve ter ouvido muitas vezes em
palestras e seminários de TI “como reutilizar
seus códigos” isso com a promessa do
desacoplamento do paradigma Orientado ao
Objeto. O sonho da escalabilidade de TI. A
frase de Antoine Lavoisier “Na natureza nada
se cria, nada se perde, tudo se transforma.”
Era só na natureza mesmo. Mas hoje
podemos pensar diferente, nossas idéias
podem ser compartilhadas ou ser até idéias de
outras pessoas, não que era assim no mundo
real mais na TI isso demorava um pouco. Para
isso temos uma revolução de integração,
podemos utilizar a teoria de Lavoisier hoje.
SOA veio para desacoplar e colocar o reuso
em prática isso se tornou uma realidade. SOA
fez da TI o próprio negócio a hoje não é
enxergada como um custo e sim uma
necessidade. Se falarmos de SOA hoje
falamos nos processos de grandes serviços
como, por exemplo, proteção ao crédito e
serviços bancários, tudo isso envolve um
grande processo integrado e uma unificação
de sistemas que diminui o custo de projetos
gigantescos que tinha duração de
anos ,redução de riscos em seus negócios,
hoje SOA esta abstraindo e universalizando a
TI. Regras de negocio são serviços rendáveis,
mas ainda é um bom negócio para que não
possa implementar podendo utilizar o que já
esta pronto sem gastar reinventando a roda.
Suas regras de negócio já não precisam ser
modificadas pelos seus Desenvolvedores e
Analistas de sistema que é um custo que ficam
á espera de uma oportunidade para possível
mudança nas regras para que possam
trabalhar. Hoje, processos, regras de negócios
podem ser enxergado de forma mais fácil, o
usuário comum, dono do negócio podem criar
e modificar suas regras de acordo com suas
políticas implementadas em um software, que
lhe mostrará sua tomada de decisão no seu
processo ou em suas regras de negócio
A Próxima Revolução em TI
O ecossistema SOA e BRMS
SILVA, Sílvio Cristiano – Universidade Cidade de São Paulo. E-mail: [email protected]
"A regra das nossas ações deve ser a probidade."
(Blaise Pascal)
1
podendo gerenciar e auditar seus negócios
com auto-suficiência. As visibilidades de
processo se encontram em ferramentas que
mostra fluxos de processo, motores de regras
como, por exemplo: BRMS (Business Rule
Management System) é um sistema de
software utilizado para definir, implementar,
executar, monitorar e manter a diversidade e a
complexidade da lógica de decisão que é
utilizada por sistemas operacionais dentro de
uma organização ou empresa. Essa lógica,
também conhecido como regras de negócio,
inclui políticas, requisitos e instruções
condicionais que são usados para determinar
as ações táticas que ocorrem em aplicações e
sistemas.
Acredita-se que BRMS é uma das
principais promessas da TI para futuro e que
vem a se destacar diante de toda SOA.
Neste capitulo, primeiramente serão
apresentados os principais conceitos da
arquitetura orientada a serviços e na
seqüência será apresentado um estudo prático
e conceitual de BRMS e sua importância na
arquitetura orientada a serviços
BRMS
A. Os problemas de integração antes eram resolvidos com
sistemas monolíticos, ou melhor, sistemas
Multiprogramáveis/Multitarefa
Constituindo-se uma evolução dos
sistemas monoprogramáveis, neste tipo de
sistema os recursos computacionais são
compartilhados entre os diversos usuários e
aplicações: enquanto um programa espera por
um evento, outros programas podem estar
processando neste mesmo intervalo de tempo.
Neste caso, podemos observar o
compartilhamento da memória e do
processador. O sistema operacional se
incumbe de gerenciar o acesso concorrente
aos seus diversos recursos, como
processador, memória e periféricos, de forma
ordenada e protegida, entre os diversos
programas.
Depois, em meados da década de 60 a 70
passaram a separar os dados dos sistemas
assim conseguiram reutilizar os dados e as
tarefas, então a partir da década de 90
passaram a separar os processos e regras de
negócio.
Assim o processo tem suas regras de
negocio que acessar uma tarefa que pode ou
inserir ou acessar um dado, Isso tudo pode
esta numa caixinha que pode ser reutilizado
por outro processo. Essa escalabilidade reduz
custo e evita erros.
Mais não foi a solução dos problemas de
integração enquanto as aplicações eram
pequenas o custo continuava baixo, mas
depois o sonho do reuso teria de serem
adiado por quer as aplicações era ponto a
ponto isso gerava um emaranhado na rede
assim aumentando o custo com manutenção.
Então surgiu uma solução chamada de
ESB. Os ESB organizam os tráficos de
mensagens utilizando cada processo como
2
serviços e esses serviços são utilizados em
uma nova regra separada, um processo que
pode consumir vários serviços e ser
orquestrado através do fluxo de trabalhos que
abstrair do ESB.
Os BRMS são componentes de software
plugáveis que separam as regras de negócios
do código do programa. Essa capacidade de
separação permite aos usuários de negócios
edite as regras freqüentemente sem a
necessidade de influência da área de TI, e
permite que as aplicações sejam mais
facilmente adaptadas às regras dinâmicas.
Um benefício fundamental de um BRMS é
sua habilidade de automatizar decisões que
antes eram tomadas manualmente.
Os BRMS tratam de definição e execução
de regras, e isso permite que sejam
implementados rapidamente grupos de regras
que irão tomar e ativar decisões e serviços
sem ter de utilizar programação.
Isso significa que a equipe de TI não
precisa mudar o código de regra de negócios
devido às exigências das leis.
Sua maior vantagem é que suas regras de
negocio podem ser administradas pelo gesto
do negocio passando a responsabilidade para
quem entendi melhor do negocio podendo
assim reduzir seu custo de implementação
não ficando na mão de programadores para
uma possível alteração em sua regra. O
BRMS também tem um grande poder de
orquestração do seu processo de regras.
De um modo simplificado podemos dizer
que o BRMS e repositório de regras de
negocio. Ele gerencia regras assim como o
SGBD gerencia dados.
Figura 1. Arquitetura Macro do BRMS
Drools.
Plain Old Java Objects (POJO) e XML
(eXtensible Markup Language).
Os pojos são o inicio de todo processo de
regras no BRMS eles definem os atores e
ações desses autores que estão envolvidas
em uma política. As regras são virtualizadas e
abstraídas de pojos e arquivos xml.
3
Figura 2 – Pojo que representa um objeto
cliente.
Regras
As ideia sobre o dia a dia do seu negocio é
normalmente armazenado sob a forma de
regras com uma forma condicional. Ao
contrário das condicionais declarações
encontradas em convencionais, linguagens de
regra são tipicamente declarativa ou
equivalentemente e não-processual, ou seja, a
ordem em que as regras são escritas não é
importante. Essas regras se baseiam no
conhecimento sobre as entidades ou objetos.
Como temos dito, outra forma importante para
representar as nossas ideias e os
procedimentos, como os encontrados em
linguagens convencionais. Existem várias
outras maneiras de representar as ideias, mas
as regras, procedimentos e objetos são os
principais elementos utilizados no BRMS no
momento. Em todos os produtos BRMS, as
regras são representadas como sentenças,
geralmente contendo as palavras se, então e
existe. É recomendo melhor estilo e objetivo
na remoção de ambigüidade, fazendo relações
explícitas. Seu estilo é incrivelmente perto
linguagem natural.
Figura 3 – Exemplo de regras
Segundo Ian Graham(1988) A maioria dos
produtos comerciais BRMS apoiar o segundo
estilo de escrita regra; apenas alguns, como
Haley Authority, apoio completamente natural
para o primeiro. Blaze Advisor oferece uma
abordagem completamente diferente sob a
forma de sua aplicação de regras de
manutenção. Estes permitem a criação das
formas de manutenção personalizada regra
que permite aos usuários interagir diretamente
com qualquer formato de apresentação de
regra considerada adequada à situação dos
negócios. Outra abordagem utilizada, por
exemplo, JRules, é permitir que o
desenvolvedor crie Verbalizações 'para o
modelo de objeto para tornar as regras mais
legíveis. Padrões de verbalizações permitem
usar frases como "concluído o contrato" em
vez do que apenas "contrato é concluído.
Essas linguagens estão tão próximas de nossa
linguagem convencional facilita a criação de
frases e um acesso fácil a multi-idiomas.
Também temos extensões como IRL,SRL e
DRL as escrever é saber como usar os
4
diferentes módulos semântica, para manter na
mentalidade a programação declarativa e de
abstrair e encapsular sua lógica. A ferramenta
de arquivo conjunto de regras pode ser usado
para construir um arquivo de conjunto de
regras.
Nesses arquivos, podemos declarar uma
única regra. Podemos adicionar elementos
como regra que quiser dentro do elemento do
conjunto de regras, e cada elemento de regra
deve ter um atributo de nome, pelo menos um
parâmetro, pelo menos uma condição e
exatamente uma consequência.
Modelos regras
Modelos regras são padrões de projeto para
as regras. Em muitas circunstâncias, uma
regra pode ser aplicável a diversos dados. Um
modelo de regra de negócio representa uma
regra de negócio parcialmente definida que
contém conectores e espaço reservado para
falta de informação. Os modelos podem ser
usados para criar várias regras com um
estrutura semelhante, onde apenas o valor
preenchido com conectores varia. Modelos de
regras poupar tempo ao escrever as regras e
ajudar a fazer cumprir uma regra padrão, e
deixa uma forma legível de escrita. Um facil
entendimento para o desenvolvedor que
pretende reutiliza-lo. Um modelo de regras
deve ser identificado e organizado a partir de
um conjunto de critérios formais tais como:
Um vocabulário de negócio que exprime
a semântica dos conceitos.
Um conjunto de proposições que
permitem a geração de conhecimento a
partir dos fatos e políticas definidas.
Procedimentos e algoritmos
Os exemplos incluem cálculos matemáticos e
financeiros. Uma boa BRMS vai oferecer a
possibilidade de invocar os procedimentos
conjuntos de regras e procedimentos para
fazer um apelo aos conjuntos de regras para
executar e retornar valores.
Fluxo de regras
Mecanismos Ruleflow dentro BRMSs deixar o
designer especifica que o conhecimento
módulos ou tarefas sejam realizadas em uma
ordem específica. Estas funções podem ser
conjuntos de regras, funções ou módulos fluxo
de regras inteiro. Uma representação do
negócio e da aplicação da lógica que tem
seqüência de regras agrupadas em tarefas
numa forma de organizar as regras
em uma seqüência de decisões que vem à
produzir um única decisão
5
Figura 4 - Exemplo de um Fluxo de regras
do Ilog Jrules IBM
Tabela de Decisão e Arvore de Decisão
Segundo Paul Browne (2009) 'Se você pode
compreender o Microsoft Excel, então você
deve estar OK'. Quase todo mundo entende
planilhas do Excel, ou seu equivalente em
OpenOffice eo Google Docs. Todos estes são
simples, editores baseado em grid que nos
permitem armazenar, editar e compartilhar
informações. Planilhas pode não ser perfeito,
mas eles são populares e bem-entendido. A
tabela de decisão é uma representação das
regras criadas pelo desenvolvedor em
planilhas essas regras podem ser gerenciadas
por um Analista de negocio utilizando as
regras do repositório BRMS.
Figura 5 – Representação de regras na tabela
de decisão.
Em alguns produtos, há representações
alternativas às regras de se / então. Nós
consideramos dois deles: árvores de decisão e
tabelas de decisão.
As árvores de decisão representam as regras
em forma de figuras, como uma estrutura de
árvore. Isso pode ser uma ajuda útil para a
depuração ou a comunicação entre usuários e
desenvolvedores ou analistas, mas
normalmente não é como os usuários de
negócios visualizarem os seus conhecimentos.
O principal problema com as tabelas de
decisão é que elas crescem
incontrolavelmente , quando há um grande
número de condições na base de regra. A
abordagem dá um maior número de regras -
uma para cada linha - e as regras será difícil
ler e compreender. Nós caracterizamos a
abordagem como a decisão de linha orientada
tabelas. Verifica a possibilidade de aumenta a
regra pode permitir que o autor de arrume o
resultante dos conjuntos de regras, mas nós
pensamos que uma abordagem de indução de
regras é muito mais sólida. É melhor utilizar
um sistema de mineração de dados para
extrair regras a partir de tabelas de decisão e
alimentá-los em um BRMS. Conseguimos
olhar para as árvores de decisão e tabelas
com mais detalhes. A principal vantagem de
tabelas de decisão surge quando a
organização já possui o conhecimento de seus
de negócio, no entanto, este vantagem em
grande parte evapora quando as regras
6
podem acessar os mesmos dados na forma de
tabelas de pesquisa.
Tabelas de decisão são apropriadas para
situações em que várias condições se repetem
regularmente em muitas regras, cada
resultando em um resultado semelhante. Cada
tabela de decisão é baseada em um
"esquema", que geralmente é criado para um
processo de decisão em particular por um
analista de negócios e acessada pelo dono do
negócio que definir as políticas.
Figura 6 – Representação de regra na
árvore de decisão
As árvores de decisão, são mas
apropriadas para situações em colunas
específicas de uma decisão tabela são
ignorados inteiramente para determinadas
condições de partida. Assim como as tabelas
de decisão, o analista de negócios teria
normalmente de cria o fluxo básico e layout de
uma árvore de decisão. As árvores de decisão
são construídas usando uma interface gráfica
podendo arrasta pacotes de regras definir
funções e dá prioridades nas execuções de
regras.
Motor de execução de regras
Um motor de execução dispõe de um ou
mais meios de aplicar o conhecimento de
dados. As estratégias mais comuns são
conhecidas como encadeamento para trás e
encadeamento para frente. Encadeamento
para trás ou raciocínio dirigido meta é típico de
seleção de produtos, sistemas de diagnóstico
ou de dá conselhos. A maioria dos sistemas
baseados em regras envolve mesclas por trás
e para frente encadeamento e outras
estratégias para reduzir a busca cega.
Implementando encadeamento para frente de
forma eficiente é difícil uma vez que, quando
um banco de regras
se torna grande, os algoritmos de
encadeamento para frente ficar muito lento
porque algumas mudanças são feitas para os
fatos na memória de trabalho em cada ciclo. O
algoritmo rete é um mecanismo muito eficiente
para resolver este problema. Rete é muito
mais eficiente na determinação da relevância
das regras, dado de dados específico, que o
equivalente as condicionais ou select e case.
A rede de rete se modifica após cada disparo
regra, de modo que regras desnecessárias
não disparam. Quanto maior o número de
regras, a maior do rete vantagem sobre o
código de procedimento equivalente. Isso se
aplica a regra de execução. De Obviamente,
escrever as regras também é muito mais
eficiente em um BRMS.
7
Os motores devem também modificar
todos os rete fundamentais para a trás e
misturado encadeamento.
Monitoramento e análise
O componente de monitoramento e
análise provê análises históricas e em
tempo de execução bem como a
geração de relatórios sobre o uso das
regras. Este componente oferece
rastreamento de auditoria completo
demonstrando como a regra foi usada
(executada) em uma transação ou
decisão em particular. Os tipos de
dados que estes relatórios produzem
incluem informação sobre como a regra
foi acessada, quais regras foram
executadas para tomar a decisão, data
e hora que a regra foi executada e o
nome dos sistemas que interagiram
com a regra. Este BRMS provê também
wizards para construção de relatórios
de regras de forma a gerar consultas
customizadas às regras (por exemplo,
relatórios de análise de impacto).
Gestão e Administração de regras
É onde podemos gerenciar as regras provê
ferramentas para deixar visíveis nos
ambientes alvos, gerenciar de segurança e
permissões sobre quem pode modificar a
regra e quando a regra pode ser modificada,
inclusão de novos conjuntos de regras e
rastreamento do desempenho dos sistemas e
servidores de execução de regras.Esse
ambiente torna fácil para gestor de políticas ter
governança de todas suas regras.
Papéis
Interação entre os papéis
As funções não se referem a pessoa,e sim
para tarefas e responsabilidades,
tarefas não podem corresponder a uma única
opinião, o especialista em negócios podem
estar envolvidos tanto no lado de negócios
como no lado técnico, o desenvolvedor pode
também ser a pessoa que escreve e gerir as
regras.
A comunicação entre o lado do negócio e
parte técnica é fundamental Interação
extensiva para assegurar a satisfação do
negócios vista, nas fases iniciais, mas também
ao longo do projeto.
• Gestor da Política
- Especialista em Negócios responsável pela
definição das políticas
- Participa na descoberta de regra e valida os
resultados
- Comentários como a execução das regras é
organizada
• Autor de regra
8
- Especialista de negócio ter domínio em
formular política em regras de negócio
- Participa na descoberta de regras
- Mantém regras atualizadas
- Relatórios sobre o estado da política da
empresa
- Regras de testes para garantir que elas
estejam escritas corretamente e garantir
resultados correspondência aos resultados de
negócios
• Analista de negócios
- Ponte entre o lado de negócios e técnicos de
uma regra de negócio aplicação
- Modelos de domínio de negócio baseado na
entrada de gestores de políticas e do Estado
dos autores
- Define o vocabulário regra
- Captura as regras
- Funciona com os desenvolvedores para
projetar a aplicação de regras de negócios
- Sincroniza o conteúdo do projeto, regra entre
usuário e desenvolvedor de Ambientes
negócios
Arquiteto
• Garante a implementação global, e a
organização de regras e otimização de
execução da regra
• Definem os tipos de regras utilizados e
orquestra a sua execução em uma
aplicação de regras de negócios
• Garante a implantação regra coerente
através de um número de regra de negócio.
Desenvolvedor
• Atua no, desenvolvimento, testes e implanta
de aplicações de regras de negócios e
execução da regra
- Exige conhecimento de modelos de objetos,
APIs e ao desenvolvimento
ambientes
• Funciona com os analistas de negócio a
implementar vocabulário regra de negócio
• Define regras de ambiente de criação para
autores regra
• Grava o código de chamada para execução
da regra
• Grava regras complexas que os usuários
empresariais não pode escrever
• Personaliza a BRMS para atender às
necessidades específicas
• Integra a BRMS no ambiente de
desenvolvimento e testes
Administrador
• Instala e configura ambientes de
gerenciamento de regras e execução
• estado aplicações Implanta
• reimplanta regras atualizadas
• Gerencia o acesso do usuário para os
servidores de gerenciamento de regras e
execução
As especificações de papeis descrita a acima
foi do livro Developing Business Rule
Applications with IBM WebSphere ILOG
JRules V7.0(2009).
9
Integrações
Os BRMS se integram geralmente com
ferramentas de BPM que faz a orquestração
de processos o BRMS faz serviço de decisões
e regras. Algumas ferramentas de BPM já
fazer suas regras e inserir essas regras em
um BRMS.
Diferentes sistemas BRMS
ILOG JRULES – IBM
HyperRETE
RuleML
PegaRULES
InRule
RuleLab.Net
NxBRE
Visual Rules
Esker DeliveryWare Business Rules Engine
CLIPS
Jess
Drools
JBoss Rules
Soar.
Conclusão
O BRMS melhora a forma como as
organizações a gerenciam a complexidade.
Eles permitem que a lógica de uma empresa
de decisão que podem ser facilmente
gerenciadas e compartilhadas através de
qualquer sistema na empresa. Políticas e
decisões são automatizadas e colocar nas
mãos de equipes de negócios, onde pode ser
alterada, testada e lançada em uma fração do
tempo de decisões humanas ou sistemas
codificados.
Administrar a complexidade destes dias é uma
adaptação rápida à mudança e sobre como
lidar com alta inconstância. A mudança ocorre
com a evolução das condições de mercado, o
cenário competitivo, novas regulamentações,
procedimentos ou políticas, objetivos novos
negócios e assim por diante. Entretanto, a
variabilidade é maior, tomar a variabilidade
representada por diferentes clientes, locais,
produtos ou processos, por exemplo. A BRMS
lida facilmente com as mudanças e variações.
Referências Bibliográficas
Graham, I. (2006a) Business Rules Management and Service Oriented Architecture A Pattern Language, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester,West Sussex PO19 8SQ, England
Browne, Paul. (2009) JBoss Drools Business RulesEditora Copyright © 2009 Packt Publishing
Developing Business Rule Applications with IBM WebSphere ILOG JRules V7.0Copyright IBM Corporation 1987, 2009. All Rights Reserved.
10
.
11
