Desafios de negócios e técnicos
Atualmente, com trocas de informações complexas com XML e grandes esquemas XSD associados, combinadas com um array de parceiros comerciais, o suporte e a manutenção da precisão do tratamento de todas as transações recebidas se tornaram desafios importantes. Atualmente, os esquemas XML e as DTDs fornecem a capacidade de validação, ou verificação, do conteúdo estrutural de um documento XML. Certas regras de validação também podem ser acomodadas como parte dos esquemas XML, mas nem todos os tipos de validação de transação podem ser executados usando esquemas XML ou DTDs.
Com a chegada das normas específicas do segmento de mercado como a Standards for Technology in Automotive Retail (STAR), coleções completas de formatos de troca de mensagens XML padrão são fornecidas na forma de esquemas XML. Os consumidores e provedores de serviços da Web devem obedecer a esses esquemas para serem certificados pelas agências de normas do seu segmento de mercado. No entanto, esses esquemas específicos do segmento de mercado são conectados de forma imprecisa com validações mínimas e podem ser usados somente para validação estrutural do XML recebido. É necessário um código adicional para implementar validações necessárias que ampliam as verificações do esquema. Essas validações evitam erros quando os dados são recebidos por aplicativos ou componentes que aguardam os dados em uma determinada estrutura e obedecem as regras de validação de conteúdo dos negócios.
A forma mais comum de implementação da lógica de validação necessária em um serviço da Web e seus aplicativos XML associados é a criação de um código customizado. Como resultado, as regras de validação são integradas aos aplicativos e não podem ser facilmente adaptadas, documentadas ou compartilhadas. Dependendo do número e da natureza das validações necessárias, o código de validação pode ser complexo, amplo e sua manutenção pode ser tornar um ônus significativo à medida que mais parceiros são incluídos. Acrescente a isso o tempo, o esforço e o risco associados a recompilação e reimplementação do código no servidor de produção sempre que a lógica de validação for alterada.
Além dos aplicativos independentes, as validações são necessárias ao expor os serviços através de um barramento de serviço corporativo (ESB). A Figura 1 ilustra a arquitetura típica de um ESB centralizado em um barramento de sistema de mensagens. O barramento fornece serviços de entrega de mensagens com base em normas como SOAP, HTTP e Sistema de Mensagens Java (JMS). O ESB permite a interação dos serviços com base na qualidade dos requisitos de serviço das transações individuais. Ele também oferece suporte para normas diferentes como SOAP, XML, WSDL, JMS, J2EE, JAX-RPC entre outras.
Figura 1. Como executar validações em uma arquitetura ESB
Um dos maiores desafios dos desenvolvedores é como executar validações de mensagens nos terminais do provedor de mensagens e do consumidor de mensagens durante a interação no ESB. Por exemplo: assim como na Figura 1, um componente de serviço da Web pode precisar de informações de um aplicativo existente. O serviço da Web (consumidor) envia uma mensagem solicitando informações do aplicativo existente (provedor) através do ESB. O componente do aplicativo requer uma solicitação em um formato específico com informações corretas e valida a mensagem de solicitação antes de processá-la. O componente dos serviços da Web possui seu próprio conjunto de requisitos e valida a mensagem de resposta Se os dois terminais usarem normas ou protocolos diferentes, o ESB poderá transformar cada mensagem, executando validações antes de transformar as mensagens.
Cada provedor e consumidor possui seus próprios requisitos. Então, dependendo do número de tipos de transação e validações, isso pode resultar em um longo ciclo de desenvolvimento para definir, criar e testar todas as validações. Essa fase de estabilização continuará até cada componente de validação ser capaz de fornecer o feedback correto sobre a validação da mensagem para o seu componente correspondente.
A abordagem da solução descrita neste artigo é a implementação dos serviços de validação XML com base na especificação OASIS Content Assembly Mechanism (CAM). A abordagem do modelo OASIS CAM é baseada em uma abordagem simples para validar e tratar o conteúdo XML que permite aos negócios criar modelos de troca comuns para trocas em XML. Os modelos de CAM oferecem suporte para regras baseadas no contexto, listas de códigos e validações de campo cruzado. Muitas validações de campo cruzado não podem ser implementadas em um único esquema XSD. Em outros casos, nos esquemas do segmento de mercado publicados não é possível acomodar todas as variações da validação.
A solução inclui o CAM Studio (um editor de modelo de UI baseado em Eclipse) que é usado para definir o modelo de CAM. E o mecanismo de validação CAMV fornece um conjunto de APIs Java de software livre que é usado para validar o XML com os modelos específicos de CAM compilados durante o tempo de execução. O editor de modelos CAM Studio oferece suporte para a inclusão de expressões XPath customizadas nos seus modelos gerados, mas a UI pode definir muitas regras sem a composição de nenhuma expressão customizada.
A Figura 2 mostra os estágios de Modelagem, Criação, Teste, Implementação e Monitoramento no ciclo de vida do desenvolvimento das regras de validação:
Figura 2. Ciclo de vida das regras de validação
Nessa etapa, as entidades e elementos de dados são identificados juntamente com suas regras de validação correspondentes. O esquema de troca XML necessário é determinado, como alternativa, os elementos necessários são mapeados para um esquema padrão de mercado existente como um esquema da STAR (Standards for Technology in Automotive Retail).
Os modelos CAM são montados ou criados usando o editor CAM Studio. Essas são as três opções de editor possíveis fornecidas para a criação de um modelo de CAM:
- Criação a partir do zero ou manual
- Uso de um esquema XML existente
- Uso de uma instância XML existente
Depois de criar um modelo de CAM, a próxima etapa é revisar todos os elementos e atributos e especificar as regras de validação aplicáveis. Um painel no editor exibe as regras de cada nó do modelo. A Figura 3 exibe uma captura de tela da estrutura do modelo no CAM Template Editor:
Figura 3. Modelo de CAM no CAM Template Editor
Apesar de todas as regras de validação não precisarem ser de natureza binária (ou seja, de aprovação ou reprovação), o CAM oferece suporte para a classificação de falhas de validação como avisos. Esse recurso é muito útil para cenários nos quais a ação corretiva pode ser executada no terminal do provedor de serviços, modificando a carga útil para tornar a mensagem utilizável ao invés de rejeitar a mensagem completa. Por exemplo: uma regra pode restringir o comprimento de um campo de comentários específico para até 255 caracteres; no entanto, ao invés de rejeitar a mensagem de solicitação quando o comprimento exceder o valor máximo, um aviso pode ser enviado ao consumidor especificando que somente os primeiros 255 caracteres serão usados no comentário.
Você verá os detalhes de como configurar uma classificação de mensagem de validação como um aviso na seção Dicas e truques deste artigo.
Os modelos de CAM são compilados usando o editor CAM Studio antes de usá-los com mecanismo CAMV de tempo de execução do aplicativo. O formato compilado é a versão XML condensada do modelo de CAM original, projetado para otimizar o desempenho do mecanismo de validação CAMV. Para compilar o modelo de CAM, selecione a opção do menu Tools > Compile Template. Isso irá gerar o formato de arquivo .cxx do modelo que será usado no tempo de execução.
O mecanismo de validação CAMV oferece uma API Java simples de software livre que pode ser usada em qualquer aplicativo Java para validar um XML de entrada com o modelo de CAM aplicável. Os fragmentos de código na Listagem 1 ilustram o uso do CAMV:
Listagem 1. Uso da API CAMV
TemplateValidator tv = new TemplateValidator(templateDocument);
tv.setErrHandler(new ElementErrorHandler(tv));
boolean tvResult = tv.validate(ioReader);
if (tvResult){
System.out.println("No errors, might be warnings.....");
}
List errList = tv.getErrors();
List warnList = tv.getWarnings();
|
As mensagens de erro ou aviso são formatadas como
<error classification>: <XPATH> => <error or warning message> => Node: <node name> => attribute: <attribute name>
Por exemplo: uma mensagem de erro deve ter a seguinte aparência:
/p:ProcessRepairOrder[1]/p:ApplicationArea[1]/p:CreationDateTime[1]=>Content does not conform to the mask:YYYY-MM-DD'T'HH:MI:SSZ =>Node: CreationDateTime
Uma mensagem de aviso deve ter a seguinte aparência:
Warning: /p:ProcessRepairOrder[1]/p:ProcessRepairOrderDataArea[1]/p:RepairOrder[1] /p:RepairOrderHeader[1]/p:OwnerParty[1]/p:SpecifiedPerson[1]/p:ResidenceAddress[1] /p:LineOne[1]=> length should be less than 80 =>Node: LineOne
Agora, com o uso do CAMV é possível exteriorizar todas as verificações de validação e não é necessário integrá-las em um código ou implementá-las usando codificação customizada. Durante o ciclo de monitoramento, é possível satisfazer as necessidades de validação adicional simplesmente atualizando os modelos de validação. Para incluir validações adicionais ou remover validações existentes, redistribua os modelos de CAM compilados (arquivos .cxx). Não é necessário recompilar e reimplementar nenhum código Java em caso de alteração da lógica de validação.
Recursos novos no release mais recente do CAMV
Alguns dos principais recursos incluídos no release mais recente (dezembro de 2009) do CAMV são:
- Foi criado um download de release compatível com versões anteriores para Java 1.5, além do Java 1.6 padrão.
- O CAMV é thread-safe, portanto, pode ser implementado em qualquer contêiner J2EE como o WebSphere® Application Server.
- Agora o CAMV aceita entradas XML como StringReader além dos documentos de JDOM, reduzindo as possíveis instâncias de serialização e desserialização durante a manipulação de mensagens.
- Agora, é possível definir diversas condições em um único elemento ou atributo XML.
Os itens a seguir são dicas e truques identificados em um projeto recente no qual o CAMV foi usado para criar uma estrutura de validação para um gateway B2B que apresentava serviços da Web baseados em STAR para a principal organização do segmento de mercado automotivo.
O CAMV oferece suporte para a criação de regras de validação para fornecer mensagens de aviso, além das mensagens de erro. Uma expressão XPath condicional precisa ser especificada no elemento XML para especificar a validação para a mensagem de aviso.
Por exemplo: considere um cenário de negócios no qual a solicitação de serviço da Web não deverá ser rejeitada se o comprimento de um campo específico exceder o limite de 255 caracteres. A decisão de negócios é truncar o comprimento do campo em 255 caracteres, caso o comprimento exceda esse tamanho, conforme requerido pelo sistema backend. No entanto, um aviso deverá ser emitido para o componente que enviou a solicitação.
Tais cenários podem ser tratados especificando uma expressão printmessage() nas regras do modelo de CAM.
O texto da mensagem deve ter um prefixo Warning: seguido pela mensagem de aviso necessária, como length should be less than
255. O texto da mensagem completo irá aparecer como Warning: length should be less than 255.
Como a mensagem será exibida somente se o comprimento do elemento exceder o comprimento especificado, essa regra é determinada como condicional e uma expressão XPath é criada para executar a verificação do comprimento conforme descrito na captura de tela da Figura 4 da ferramenta do assistente de entrada de expressão do editor CAM Studio:
Figura 4. Como configurar uma regra de aviso
Armazene o modelo de CAMV em cache
É possível armazenar modelos de CAMV em cache na memória para executar validações repetidas, para não ter que ler os modelos do disco rígido em cada validação executada. Isso reduz a E/S do disco e melhora significantemente o desempenho e o rendimento.
Verificando erros de validação
O método Java CAMV TemplateValidator.validate(..) retorna o valor true mesmo se forem retornados avisos. Ele está definido como false somente quando forem retornados erros.
Então, em eventos nos quais somente avisos são retornados, use o método getWarnings() para obter a lista das mensagens de aviso.
Se as mensagens retornadas (que contêm o caminho XPath, uma mensagem de validação e um nome de nó) não forem suficientes para o cenário de negócios e forem necessárias mais informações, o aplicativo cliente pode criar um código customizado. O CAMV retorna o mesmo XML de entrada após incluir os atributos CAMERROR e CAMWARN ao XML de mensagem de troca, conforme descrito na Listagem 2.
Listagem 2. XML modificado após a execução da validação
<p:ApplicationArea> <p:Sender> <p:CreatorNameCode>CNV</p:CreatorNameCode> <p:SenderNameCode>SNC</p:SenderNameCode> </p:Sender> <p:CreationDateTime CAMERROR="CreationDateTime | Content does not conform to the mask:YYYY-MM-DD'T'HH:MI:SSZ">2001-12-31T12:00:00</p:CreationDateTime> <p:Destination/> </p:ApplicationArea> <p:ResidenceAddress> <p:LineOne CAMWARN="WARNING:LineOne | length should be less than 80">100 Moon Drive 100 Moon Drive 100 Moon Drive 100 Moon Drive 100 Moon Drive 100 Moon Drive</p:LineOne> <p:LineTwo>APT # 100</p:LineTwo> <p:CityName>MALIBU</p:CityName> <p:CountryID>US</p:CountryID> <p:Postcode>99999</p:Postcode> <p:StateOrProvinceCountrySub-DivisionID>CA</p:StateOrProvinceCountrySub-DivisionID> </p:ResidenceAddress> |
Ao inserir regras no modelo, as expressões de validação XPath são especificadas (por padrão) usando expressões curinga com duas barras (//) que selecionam todos os nós no documento, a partir do nó atual, que correspondem à seleção, independente do local.
Figura 5. Como especificar expressões curinga ao definir regras
Isso resulta na aplicação das regras em todas as instâncias de um determinado elemento. (Observação: talvez as regras podem não fiquem visíveis imediatamente para todas as outras instâncias de um determinado elemento. Isso poderá ocorrer somente quando o modelo for atualizado na visualização do editor de modelo de CAM).
No entanto, caso seja necessário aplicar a verificação em uma instância específica de um elemento XML, é recomendado selecionar Full na caixa de seleção Rule XPath.
Figura 6. Como especificar expressões explícitas ao definir regras
Usando CAMV, é possível impingir verificações de validação sistematicamente e alterar rapidamente as regras para ajustar a manipulação de mensagens para corresponder às trocas e aos conteúdos de um parceiro específico. Ao exteriorizar as regras de validação, que normalmente são integradas no código do aplicativo backend, ocorre uma melhora no controle e no gerenciamento, além da melhora na previsibilidade da manipulação de mensagens. Opcionalmente, esses modelos de regras baseados em normas podem ser compartilhados com parceiros para facilitar a melhora do alinhamento de manipulação de conteúdo nos sistemas.
Com um processo mais adaptado e tolerante a falhas, o aplicativo é capaz de tratar uma variação maior de conteúdos e assim oferecer suporte mais facilmente para um amplo conjunto de parceiros de interação com custos de suporte e manutenção reduzidos—o que é o oposto das experiências normais
O uso de software livre facilitou muito a colaboração no desenvolvimento da solução e na integração do mecanismo CAMV no ambiente de implementação.
No geral, esse projeto demonstrou que o uso inovador de XML e modelos de regras XML configuráveis dinamicamente pode fornecer uma experiência de aplicativo para o cliente melhor, mais estável, mais rápida e eficiente do que o uso isolado de recursos de código compilado estático.
| Descrição | Nome | Tamanho | Método de download |
|---|---|---|---|
| Sample Java project that uses CAMV Java APIs | ValidationFrameworkSample.zip | 2032KB | HTTP |
Informações sobre métodos de download
Aprender
- Mecanismo JCAM com editor/validador XML: Consulte informações sobre o projeto CAMV no Web site da SourceForge.
- O Wiki OASIS CAM: Visite um site de recursos para usuários e desenvolvedores de modelos e processadores de CAM.
- Meet CAM: A new XML validation technology (Brian M. Carey, developerWorks, setembro de 2009): Leia uma introdução e visão geral do CAM.
- Taking XML Validation to the Next Level: Introducing CAM: Leia uma série de artigos que representam CAM: O manual que faltava.
- Área de XML do developerWorks: Obtenha os recursos necessários para melhorar suas qualificações na esfera de XML.
- Certificação XML da IBM: Descubra como se tornar um Desenvolvedor Certificado pela IBM em XML e tecnologias relacionadas.
- Biblioteca técnica de XML: Consulte a zona de XML para obter uma ampla gama de artigos técnicos e dicas, tutoriais, padrões e Redbooks da IBM.
- Eventos técnicos e webcasts do developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
- developerWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
- Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
Obter produtos e tecnologias
- Padrão de especificação do OASIS CAM: Faça download e revise as especificações do CAM.
- Versões de avaliação de produtos IBM: Faça o download ou explore as versões de teste on-line no IBM SOA Sandbox e entre em contato com as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli®e WebSphere®.
Discutir
- Fóruns de discussão da zona de XML: Participe de qualquer uma das várias discussões relacionadas à XML.
- Blogs do developerWorks: Confira esses blogs e participe.

Puneet Kathuria é Arquiteto de Integração e trabalha na IBM India Ltd. Ele possui mais de 13 anos de experiência, principalmente em arquiteturas de aplicativos e de integração, e está na IBM há 4 anos.

David atualmente é consultor no desenvolvimento do NIEM IEPD para o governo dos EUA e reside em Washington DC, EUA. David é coordenador do comitê técnico do OASIS CAM e codesenvolvedor do editor CAM Studio Eclipse, responsável pela maioria dos scripts de processamento XSLT. David possui mais de 30 anos de experiência no segmento de mercado e, em 2007, foi reconhecido como membro senior do ACM por seu trabalho em XML. David é autor de diversos artigos sobre XML, otimização da troca de informações e especificações de normas para OASIS e, frequentemente, ministra palestras sobre XML na América do Norte, Europa e Ásia.

Martin é um consultor com mais de 20 anos de experiência que reside em Suffolk, na Inglaterra, especializado em XML, Ontologias, Java, Eclipse e soluções da Web. Martin é o autor das especificações originais do OASIS CAM e das implementações do mecanismo de validação do editor CAM Studio Eclipse e CAMV. Martin também já participou ativamente de trabalhos no segmento de mercado de telecomunicações em trabalhos de normas e trocas de mensagens baseadas em XML na Europa. Ele se apresentou em diversos eventos do segmento de mercado, incluindo as exposições de tecnologias patrocinadas pela OASIS na Europa.