Com qualquer tecnologia baseada em regras, o processamento baseado em regras envolve três áreas básicas, o vocabulário que forma a linguagem, a gramática para expressar o vocabulário em instruções e o mecanismo de processamento de regras. Este tópico descreve o vocabulário e a gramática. O mecanismo de processamento de regras é reutilizável a partir de componentes comuns.
O vocabulário consiste nos operadores, palavras-chaves variáveis conhecidas como operandos e instruções de fluxo de controle. A linguagem de opção é JMS (Java Message Service) 1.1, especificamente o Message Selector Syntax. O seletor de mensagem é uma cadeia cuja sintaxe é baseada em um subconjunto da expressão condicional SQL92. Neste aplicativo, ele expressa uma regra de classificação. A sintaxe da instrução geral é:
expression em que a expressão é uma cláusula where condicional de consulta SQL válida que contém predicados; por exemplo,
serverhost like ‘%ibm.com’
Nessa expressão, serverhost é o operando, like é o operador e '%ibm.com' é o literal ou valor que serverhost deve ter para que a expressão seja avaliada como verdadeira. O resultado de uma expressão é uma ação executada. Do ponto de vista da gramática, estas ações são literais fornecidos por um provedor de políticas. Dois tipos de políticas são suportados, políticas de roteamento e de serviço. Portanto, as ações executadas são indicadas pelo provedor de políticas. Para roteamento, as ações são permit, reject, redirect e permitsticky. Cada uma das ações tem o destino apropriado; o destinatário de uma ação. Se o resultado da avaliação de uma expressão é executar a ação permit, o destino dessa ação será o aplicativo para o qual o roteamento é permitido. Para políticas de serviço, o destino é encapsulado na ação e a ação é uma classe de transação.
Uma instrução completa consiste na expressão da regra e a ação a ser executada é representada de forma diferente, dependendo da origem de entrada. Com o console administrativo, as ações são separadas em formulários e campos que podem ser facilmente selecionados. Se você estiver Gerenciando Classes de Trabalho com Scripts, a instrução completa pode ser semelhante a esta:
expression<delimeter>action Por exemplo, clienthost='localhost' and serverhost like '%.ibm.com'?permit?DefaultApplication.ear
No entanto, do ponto de vista da implementação, as classes de trabalho, que são documentos XML, são utilizadas para capturar a expressão de regras, ações correspondidas e outros artefatos de implementação. Portanto, uma classe de trabalho é um documento XML que contém zero ou mais elementos matchRules e um ou mais elementos workClassModules. Para obter informações adicionais, consulte Roteamento e Políticas de Serviço para Classes de Trabalho.
O WebSphere Extended Deployment suporta os operadores nas expressões de regras. Em geral, você pode não saber qual é o verdadeiro tipo de dados de um determinado operando. No entanto, você pode seguir a forma de HTTP de tratar todo operando como uma cadeia de tipo de dados e utilizar o operador como um indicador para o tipo de dados real do operando para fins de validação dos dados. Um exemplo de um operador que testa um operando que tenha um valor NULL é: IS NULL.
Related reference
Políticas de Roteamento para
Classes de Trabalho