BRPI1105718A2

BRPI1105718A2 - métodos e sistemas implementados em computador para processar e gerar documento xml, para converter documento xml em arquivo simples, para processar, gerar e converter documento xml e produto de programa de computador

Info

Publication number: BRPI1105718A2
Application number: BRPI1105718A
Authority: BR
Inventors: Rakesh Sharma; Yulia Groza
Original assignee: Wal Mart Stores Inc
Priority date: 2010-12-15
Filing date: 2011-12-09
Publication date: 2016-05-24
Also published as: CA2759618A1; US20120159306A1; JP2012128853A

Abstract

métodos e sistemas implementados em computador para processar e gerar documento xml,para converter documento xml em arquivo simples,para processar, gerar e converter documento xml e produto de programa de computador. um sistema e método melhorados para processar documentos xml combina um analisador de fluxo contínuo baseado em puxar, tal como stax, com uma estrutura de ligação a objeto xml, tal como xmlbeans. desta maneira, documentos xml de tamanho arbitrário podem ser processados sem estar sujeitos a limitações de memória.além disso, várias modalidades da presente invenção proporcionam uma estrutura que isola código de aplicativo de stax e xmlbeans. objetos de dados de aplicativo não precisam estar cientes de stax e xmlbeans. código pode, dessa forma, ser mais facilmente mantido e pode ser trocado, intensificado ou de outra forma modificado sem afetar negativamente a operação dos aplicativos.

Description

“MÉTODOS E SISTEMAS IMPLEMENTADOS EM COMPUTADOR PARA PROCESSAR E GERAR DOCUMENTO XML, PARA CONVERTER DOCUMENTO XML EM ARQUIVO SIMPLES, PARA PROCESSAR, GERAR E CONVERTER DOCUMENTO XML E PRODUTO DE PROGRAMA DE COMPUTADOR” RELATÓRIO DESCRITIVO Campo da Invenção [0001] A presente invenção refere-se a sistemas e métodos para processar documentos Extended Markup Language (XML) e, mais particularmente, a uma estrutura para permitir a geração, análise e processamento de tais documentos de tamanho arbitrário sem se preocupar com as limitações de memória.

Descrição da Técnica Relacionada [0002] XML (Extensible Markup Language) é um conjunto de regras para codificação de documentos por via eletrônica amplamente utilizado. Várias interfaces de programação estão disponíveis para acesso a dados XML, e existem muitos formatos baseados em XML para uso e desenvolvimento de software. Embora exista uma especificação XML, muitas vezes é necessário converter documentos XML de um formato para outro, para que eles podem ser compreendidos por diferentes aplicativos. Tal conversão pode ser necessária, por exemplo, ao integrar sistemas distintos tendo diferentes versões da especificação XML.

[0003] Os analisadores XML processam documentos XML em uma variedade de maneiras. Geralmente, esses analisadores empregam uma interface de programação de aplicativo (API) para acessar o XML.

[0004] As APIs existentes para processamento XML tendem a cair em uma das seguintes categorias: - APIs Seriais (ou orientadas para fluxo) (por exemplo, API Simples para XML (SAX); - APIs transversais de árvore acessíveis de uma linguagem de programação, tal como Document Object Model (DOM); - Ligação de dados XML que fornece uma tradução automática entre um documento XML e objetos de linguagem de programação; - Linguagens de transformação declarativas, tal como XSLT e XQuery.

[0005] Em APIs seriais, tal como SAX, os dados são processados de forma serial usando um modelo de envio orientado por eventos. Nenhuma representação na memória do documento XML é construída. O documento XML é atravessado linearmente, com apenas uma porção sendo carregada na memória a qualquer dado momento. Quando o analisador encontra declarações XML, ele gera eventos que são capturados pelo aplicativo de software. Assim, o analisador não tem acesso a todo o documento XML simultaneamente.

[0006] Aplicativos que usam essas APIs seriais definem um número de métodos de retorno de chamada que são chamados pelo analisador quando os eventos são disparados durante a análise de um documento XML.

[0007] Evitando a necessidade de reter todo o documento XML em memória a qualquer dado momento, as APIs seriais permitem processamento de documentos XML arbitrariamente grandes, ao mesmo tempo em que mantêm uma base de memória relativamente econômica. A base de memória de uma API serial se baseia na profundidade máxima do arquivo XML (a profundidade máxima da árvore XML) nos dados máximos armazenados em atributos XML em um simples elemento XML, que são muitas vezes menores do que a memória necessária para reter todo o documento XML.

[0008] No entanto, para certos tipos de transformações de dados, a abordagem serial pode não ser eficaz, especialmente se tais transformações exigem que o documento inteiro XML esteja disponível simultaneamente (em outras palavras, o analisador não pode executar a transformação de forma serial). Além disso, o analisador geralmente não pode manter relações pai/filho entre os elementos do documento XML. Aplicativos que usam APIs seriais precisam fornecer manipuladores (retornos de chamada) para lidar com todos os eventos disparados. APIs seriais, assim, colocam uma carga maior sobre o aplicativo para manter essas relações pai/filho e para realizar as transformações que exigem que o documento inteiro XML esteja disponível. Esta carga maior sobre aplicativos torna as APIs seriais limitadas em sua utilidade.

[0009] APIs transversais à árvore e de ligação a dados podem evitar tais problemas. Por exemplo, um Document Object Model (DOM) representa o XML como uma hierarquia de árvore de objetos de nó e fornece um conjunto padronizado de interfaces para acessar nós e a hierarquia subjacente. Análise de XML pode ser executada atravessando a árvore. Embora as interfaces fornecidas por DOM possam ser mais fáceis de usar, elas geralmente requerem que toda a árvore permaneça na memória. Uma árvore na memória precisa de espaço muito maior do que o documento XML que ela representa e, portanto, pode não ser prática para documentos XML muito grandes.

[0010] Da mesma forma, ferramentas de ligação de objeto XML, tal como XMLBeans, Castor e Java Architecture for XML Binding (JAXB) mantêm o modelo de objeto inteiro que representa o documento XML em memória.

[0011] Por exemplo, XMLBeans é uma estrutura de ligação de Ja- va para XML que permite aos desenvolvedores de Java acessar e processar dados XML sem precisar saber de XML ou processamento de XML. XMLBeans simplifica o acesso a um documento XML de um aplicativo Java, apresentando o documento XML para o aplicativo na forma de objetos Java. Por outro lado, ele fornece as ferramentas necessárias para converter estes objetos Java de volta em um documento XML.

[0012] XMLBeans tem suporte completo de esquema XML e fornece o mapeamento de esquema para classes Java equivalentes e constructos de digitação tão naturalmente quanto possível. XMLBeans usa Esquema XML para compilar interfaces Java e classes que podem ser usadas para acessar e modificar dados de exemplo XML.

[0013] XMLBeans, portanto, fornece uma visualização baseada em objeto Java de dados XML que preserva a estrutura original XML nativa. Ele também preserva a integridade do documento XML. O documento de exemplo XML inteiro é tratado como um todo. Os dados XML são armazenados na memória como XML. Isto significa que a ordem do documento é preservada, assim como o conteúdo do elemento original com espaço em branco.

[0014] XMLBeans pode ser uma ferramenta muito útil para situações de programação XML nas quais o documento está disponível na memória. No entanto, esse modelo em memória sofre das mesmas limitações conforme descrito acima para um DOM ou outra técnica de árvore transversal: o aplicativo pode rodar fora da memória durante o processamento de documentos XML grandes.

[0015] Por conseguinte, em qualquer uma das abordagens acima descritas transversais à árvore ou de ligação de dados, o tamanho do documento XML que pode ser processado é limitado pela quantidade de memória disponível. Além disso, em tais implementações, o código do aplicativo é muitas vezes necessariamente recheado com o código de ferramenta de ligação de objeto XML. A falta de separação entre a lógica de negócios e códigos de ferramenta XML pode tornar difícil e/ou confuso para usar ou manter esse sistema.

[0016] As linguagens de transformação declarativas, tal como XSLT (Transformações XSL) e XQuery também são capazes de transformação de documentos XML. No entanto, essas linguagens são limitadas na capacidade. Por exemplo, em tais sistemas, o documento XML é normalmente representado pelo DOM e, portanto, herda as limitações do DOM. Além disso, não há representação de objeto dos dados XML; XSLT é somente usado para transformar dados de um formato para outro.

[0017] Outra abordagem usa Streaming API para XML (StAX). StAX opera como um compromisso entre os modelos baseados em eventos e árvore oferecidos, respectivamente, por APIs seriais e DOMs. Na metáfora StAX, o ponto de entrada programático é um cursor que representa um ponto dentro do documento. O aplicativo orienta o analisador, essencialmente movendo o cursor através do documento, de modo a extrair informações como ele precisa. Isto está em contraste com uma API à base de evento (tal como SAX) que envia dados para o aplicativo requerendo que o aplicativo mantenha o estado entre eventos conforme necessário para manter o controle da localização dentro do documento.

[0018] Como o SAX, StAX pode processar arbitrariamente grandes tamanhos de documentos XML e ainda o controle permanece com o aplicativo em vez do analisador. O aplicativo informa ao analisador para obter o próximo bloco de dados quando ele quiser receber em vez do analisador informar ao aplicativo quando o próximo bloco de dados está pronto. Além disso, StAX é capaz de ler documentos XML existentes e também pode criar novos documentos XML sem qualquer limite de tamanho. SAX é um analisador unidirecional e não pode ser usado para gerar novos documentos XML, enquanto StAX é uma API bidirecional.

[0019] StAX, assim, trabalha bem para processar documentos grandes um seção de cada vez, essencialmente movendo do início do documento para o final de uma forma sequencial. No entanto, StAX não é uma boa solução quando o aplicativo precisa acessar partes amplamente separadas do documento simultaneamente e em sequência potencialmente imprevisível.

[0020] O que é necessário, portanto, é um sistema e método de processamento XML que fornece as vantagens de uma API serial enquanto permitindo acesso aleatório a diferentes porções do documento e sem requerer que o aplicativo esteja envolvido com detalhes de baixo nível de análise. O que é ainda necessário é uma técnica que não esteja sujeita a limitações rigorosas de memória que são encontradas nos métodos acima descritos de árvore transversal, tal como DOM. O que é ainda necessário é um esquema de análise XML que evite as limitações e desvantagens dos métodos do estado da técnica.

Sumário da Invenção [0021] Em várias modalidades, a presente invenção fornece um sistema e método aperfeiçoados para processar documentos XML combinando um analisador de fluxo contínuo baseado em envio, tal como StAX, com uma estrutura de ligação de objeto XML, tal como XMLBeans. Desta forma, a presente invenção é capaz de processar documentos XML de tamanho arbitrário sem estarem sujeitos a limitações de memória.

[0022] Além disso, várias modalidades da presente invenção fornecem uma estrutura que isola o código de aplicativo de StAX e XMLBeans. Objetos de dados de aplicativo não precisam estar cientes de StAX e XMLBeans. Código pode assim ser mais facilmente mantido; o uso do analisador XML (StAX) juntamente com a estrutura de ligação de objeto XML (XMLBeans) permite que o código seja trocado, intensificado ou de outra forma modificado sem afetar negativamente o funcionamento dos aplicativos.

[0023] Em várias modalidades, o sistema e o método da presente invenção também fornecem os seguintes recursos e vantagens: - Validação de esquema configurável e delegação de manipulação de mensagens de erro de validação para aplicativo, de modo que elas podem ser tratadas por manipuladores específicos de aplicativo. - Pulo/inclusão configuráveis de segmentos que falham na validação de XML Schema Definition (XSD). - Personalização configurável de mensagens de erro XSD para ajudar a identificar registros que falham na validação XSD. - Transformações configuráveis de arquivos XML em arquivos simples através de XPaths. - Geração incrementai de XML de objetos de dados de aplicativo. - Extração serial e processamento de segmentos XML enquanto fornecendo objetos de dados de aplicativo correspondentes.

[0024] A combinação de um analisador de fluxo à base de envio, tal como StAX, com uma estrutura de ligação de objeto XML, tal como XMLBeans, permite que o analisador XML da presente invenção opere em documentos XML de qualquer tamanho, enquanto facilitando o mapeamento de esquema para interfaces/classes Java equivalentes, de modo que os programadores possam lidar com objetos Java ao invés de processamento XML de baixo nível. Um documento XML, assim, pode ser processado em segmentos como necessário pelo aplicativo. Um segmento é extraído de cada vez do documento XML; XMLBeans é usado para carregar o segmento extraído em objetos. Inversamente, um documento XML pode ser criado gerando segmentos XML de objetos XMLBeans e usando StAX para transmitir o XML gerado. Desta forma, um documento XML de qualquer tamanho pode ser gerado incremen-talmente.

[0025] Em uma modalidade, objetos de dados de aplicativo são isolados do código StAX e XMLBeans, fornecendo uma camada separada de tradução para fornecer mapeamento entre objetos XMLBeans e objetos de dados de aplicativo. Código relacionado a XMLBeans, portanto, não prolifera em outras partes do aplicativo, pois ele estará contido somente dentro da camada de tradução. Por conseguinte, os desenvolvedores familiarizados com XMLBeans podem concentrar-se na camada de tradução, enquanto os desenvolvedores de aplicativos podem concen-trar-se na implementação da porção lógica de negócios sem jamais precisar entender StAX ou XMLBeans.

Breve Descrição dos Desenhos [0026] Os desenhos em anexo ilustram várias modalidades da invenção e, juntamente com a descrição, servem para explicar os princípios da invenção. Aqueles versados na técnica reconhecerão que as modalidades particulares ilustradas nos desenhos são meramente exemplares e não se destinam a limitar o escopo da presente invenção.

[0027] A Fig. 1 é um diagrama de blocos representando um exemplo de uma arquitetura para praticar a invenção de acordo com uma modalidade.

[0028] A Fig. 2A é um diagrama de rastreamento de evento representando um método para processar um documento XML de acordo com uma modalidade.

[0029] As Figuras 2B e 2C são um diagrama de rastreamento de evento representando um método para processar um documento XML de acordo com outra modalidade.

[0030] As Figuras 3A e 3B sao diagramas de rastreamento de evento representando um método para gerar um documento XML de acordo com uma modalidade.

[0031] As Figuras 4A e 4B sao diagramas de rastreamento de evento representando um método para converter um documento XML em um arquivo simples de acordo com uma modalidade.

[0032] A Fig. 5 é um diagrama de fluxo representando uma visão geral de um método para processar um documento XML de acordo com uma modalidade.

[0033] A Fig. 6 é um diagrama de fluxo representando uma visão geral de um método para gerar um documento XML de acordo com uma modalidade.

[0034] A Fig. 7 é um diagrama de classe para uma classe produtora de acordo com uma modalidade.

[0035] A Fig. 8 é um diagrama de classe para uma classe de consumidor de acordo com uma modalidade.

Descrição Detalhada das Modalidades Arquitetura do sistema [0036] Com referência agora à Fig. 1, é mostrado um diagrama de blocos representando um exemplo de uma arquitetura para praticar a invenção de acordo com uma modalidade. O sistema de análise XML 100 inclui estrutura 102, configurator 103, analisador StAX 104, XMLBeans 105 e camada de tradução 106. O documento XML 107 pode vir de qualquer fonte tal como, por exemplo, um armazenamento de dados 108 que pode ser local ou remoto com relação a outros componentes da presente invenção. O aplicativo 101 é qualquer aplicativo de software que requer dados do documento XML 107. A estrutura 102 é um módulo funcional para controlar a geração de documentos XML 107, bem como a extração e análise de dados de um documento XML existente 107. A estrutura emprega e interage com outros componentes para implementar as técnicas da presente invenção, incluindo analisa-dor StAX 104 para análise de fluxo de documento XML 107 e XMLBe-ans 105 para implementação de uma estrutura de ligação de objeto que isola o código de aplicativo de XML bruto. A camada de tradução 106 gera objetos de domínio de objetos XMLBeans, a fim de fornecer mapeamento entre objetos XMLBeans e objetos de dados de aplicativo. O configurador 103 fornece informações para a estrutura 103 quanto à estrutura do XML, classe de tradutor, inclusão/exclusão de registros inválidos, se executar validação XSD, XML para configuração de transformação de arquivo simples, etc.

[0037] Os vários módulos funcionais mostrados na Fig. 1 podem ser implementados como software rodando em entidades separadas de computação ou eles podem ser combinados em qualquer configuração desejada. Eles podem ser implementados de maneira distribuída através de qualquer número de dispositivos de hardware. A comunicação entre os módulos funcionais pode ocorrer através de qualquer meio de comunicação digital conhecido e usando protocolos de rede conhecidos, tal como TCP/IP e HTTP. A disposição particular de módulos funcionais na Fig. 1 e de outra forma descrita neste documento é destinada a ser ilustrativa de uma modalidade da presente invenção e não deve ser considerada como limitando o escopo da invenção de qualquer maneira.

[0038] De acordo com as técnicas da presente invenção, o sistema de análise XML 100 facilita o processamento de documentos XML de tamanho arbitrário, sem estarem sujeitos a limitações de memória, e em que objetos de dados de aplicativo são isolados do código StAX e XMLBeans fornecendo uma camada separada de tradução 106 para fornecer mapeamento entre objetos XMLBeans e objetos de dados de aplicativo.

[0039] Em uma modalidade, sistema 100 fornece um mecanismo pelo qual o aplicativo 101 pode estar no controle, de modo que o aplicativo 101 solicita dados da estrutura 102 quando necessário, em um paradigma à base de envio. Além disso, em uma modalidade, o sistema 100 emprega uma estrutura de ligação de objeto (tal como XMLBeans 105) para permitir que o sistema 100 opere em documentos XML de qualquer tamanho, enquanto facilitando o mapeamento de esquema para interfaces/classes Java equivalentes, de modo que os programadores possam lidar com objetos Java ao invés de processamento XML de baixo nível.

[0040] Em uma modalidade, em resposta a uma solicitação do aplicativo 101, a estrutura 102 extrai uma porção do documento XML 107 conforme necessário para satisfazer a solicitação. A porção XML extraída é passada para XMLBeans 105, que gera um modelo na memória dessa porção e a retorna para a estrutura 102 para apresentação ao aplicativo 101. Desta maneira, é evitada a necessidade de representar o documento XML inteiro 107 na memória.

[0041] Em uma modalidade, a camada de tradução 106 traduz o modelo na memória gerado por XMLBeans 105, de modo que ele esteja na forma de objetos de domínio compreensíveis pelo aplicativo 101. Por exemplo, se um aplicativo solicita um objeto de empregado, incluindo um primeiro nome, sobrenome, endereço e assim por diante, mas o XML que representa esses dados tem um formato diferente, a camada de tradução 106 executa a tradução necessária. Método de operação [0042] De acordo com as técnicas da presente invenção, pelo menos três tipos de operações estão disponíveis: processamento de um documento XML para obter objetos de dados de aplicativo correspondentes aos segmentos e subsegmentos XML; gerando um documento XML dos dados de aplicativo e convertendo um documento XML em um arquivo simples.

[0043] Com referência agora à Fig. 5, é mostrado um diagrama de fluxo representando uma visão geral de um método para processar um documento XML de acordo com uma modalidade. O aplicativo 101 solicita 502 um objeto de dados. A estrutura 102 solicita 503 e recebe um bloco de dados do analisador StAX 104. Por exemplo, se o aplicativo 101 solicitou dados que representam um empregado, o bloco de dados do analisador StAX 104 pode ser o próximo bloco de dados que representam um empregado. A estrutura 102, em seguida, passa 504 o bloco de dados para a camada de tradução 106 que executa uma conversão e retorna 505 a árvore de objetos equivalentes no formato XMLBeans. Uma vez que a estrutura 102 recebe a árvore de objetos, ela chama 506 a camada de tradução 106 para converter o objeto em um formato que o aplicativo 101 pode compreender. A camada de tradução 106 traduz a árvore de objetos para um formato, de modo que o resultado seja livre de APIs de baixo nível XML, objetos XMLBeans e outros artefatos com os quais o aplicativo não está preocupado.

[0044] Com referência agora à Fig. 6, é mostrado um diagrama de fluxo representando uma visão geral de um método para gerar um documento XML de acordo com uma modalidade. O aplicativo 101 passa um objeto de dados para a estrutura 102. A estrutura 102 chamada a camada de tradução 106 para executar a tradução para um objeto XMLBeans. Uma vez que a tradução ocorre, a estrutura 102 usa 603 o objeto XMLBeans para extrair XML equivalente. A estrutura 102, em seguida, grava 605 o XML no armazenamento de dados 108. Em uma modalidade, a etapa 605 envolve começar a criação de um novo documento XML ou anexar o XML a um documento XML existente que começou anteriormente. Desta maneira, a criação de documentos XML em pedaços ou em fluxo é facilitada.

[0045] Em uma modalidade, a estrutura 102 faz a gravação do XML, tão logo um limite de memória especificado é atingido. O analisa-dor StAX 104 é usado para determinar qual porção do XML deve ser gravada e qual porção deve ser mantida na memória para ser gravada quando todos os subsegmentos são gravados. Por exemplo, suponha que o XML a seguir será gerado: <employees> <employee>......</employee> <employee>......</employee> <employee>......</employee> </employees>

[0046] Isto é feito gerando cada segmento de empregado (“emplo-yee”) incrementalmente dentro do segmento de “employees”. Em uma modalidade, as seguintes etapas são executadas para gerar o XML: 1) Primeiro gerar o segmento “employees”, mas não gravar a sua etiqueta de final (</employees>). Manter o segmento gerado na memória. A estrutura 102 passa o XML para o analisador StAX 104 e pede a ele para quebrar o XML em etiquetas individuais, tal como etiquetas de abertura e fechamento. A estrutura 102, em seguida, grava todas as etiquetas que não aquela de final. Aqui, a estrutura 102 está fazendo uso do analisador StAX 104 para identificar as etiquetas individuais dentro do segmento XML. 2) Continuar adicionando elementos “employee”. A estrutura 102 continua acrescentando XML correspondente aos dados de empregados. 3) Gravar etiqueta de final </employees> uma vez que o aplicativo 101 indique que todos os elementos “employee” foram adicionados.

[0047] Em uma modalidade, o sistema da presente invenção também é capaz de realizar conversões de documentos de vários tipos. Por exemplo, às vezes é útil converter documentos XML em arquivos simples; tal conversão pode ser utilizada para upload bruto de arquivos de dados quando operando em conexão com componentes (tal como o SQL*Loader) que podem não ser capazes de carregar XML. Ao executar a conversão de documentos, às vezes pode ser necessário obter dados de diferentes partes do documento XML original ao gerar o arquivo simples. Cada bloco de dados geralmente corresponde a uma linha (ou inúmeras linhas) no arquivo simples resultante. No entanto, dados para popular a linha podem vir de outro bloco, por exemplo, um que pode precisar ser obtido de uma fonte diferente (ou combinação de fontes). Em uma modalidade, o configurador 103 interpreta um bloco de dados inicial que identifica remetentes de outros blocos de dados, de modo que esses dados que são necessários para gerar uma linha de arquivo simples podem ser recuperados e mantidos na memória tanto quanto necessário para gerar a linha do arquivo simples. Elementos de dados que são cruzados pelo bloco de dados sendo processado podem, dessa forma, ser recuperados conforme necessário. Desta maneira, o configu-rator 103 garante que os elementos de dados necessários são recuperados e estão presentes, enquanto ainda mantém o uso de memória em uma quantidade gerenciável. Em uma modalidade, a linha no arquivo simples especifica a origem dos dados.

[0048] Por exemplo, suponha que as informações de um parceiro (isto é, uma fonte auxiliar de dados) são necessárias para a obtenção de informações relevantes na geração de arquivo simples. A primeira porção de dados do documento XML pode especificar o parceiro. A identificação do parceiro é relevante para a obtenção de informações adicionais para o processamento de outros blocos de dados. Assim, a estrutura mantém o nome do parceiro na memória durante o processamento de outros blocos de dados, de modo a facilitar a geração do arquivo simples. O configurador 103 fornece a estrutura 102 com as informações necessárias para determinar quais elementos de dados devem ser mantidos na memória e que podem ser descartados uma vez que eles tenham sido processados.

[0049] Em uma modalidade, o configurator 103 especifica essas informações usando um documento XPath. O documento XPath indica quais itens de dados são cruzados e indica ainda que blocos de dados requerem que quais dados estejam presentes. XPath, o XML Path Language, é uma linguagem de consulta bem conhecida para selecionar nós de um documento XML. Dadas estas informações, a estrutura 102 é capaz de reter referências cruzadas na memória tanto tempo quanto necessário e descartar aqueles itens que não são mais necessários. O documento XPath pode variar de um tipo XML para outro.

[0050] Em uma modalidade, uma vez que as referências cruzadas não são mais necessárias, elas podem ser descartadas mesmo se a conversão de documentos ainda não estiver completa, por exemplo, se houver uma necessidade de liberar memória. Em outra modalidade, as referências cruzadas são mantidas até que seja concluída a conversão de documentos. Em outra modalidade, referências cruzadas que não são mais necessárias são trocadas para disco ou outro armazenamento, de modo que elas podem ser disponibilizadas posteriormente.

Processamento de um documento XML

[0051] Em uma modalidade, o sistema da presente invenção pode processar um documento XML 107 para gerar objetos de domínio de aplicativo utilizáveis pelo aplicativo 101 na execução de alguma operação (tal como atender a uma solicitação de cliente). Documentos XML 107 podem conter muitos tipos diferentes de informações incluindo, por exemplo, etiquetas “para” e “de” indicando onde o documento deve ir e de onde ele vem. Um exemplo de um documento XML que contém informações sobre empregado é o seguinte: <wmi> <header> <to .... /> <from .../> < /header> <employees> <employee> <employee> < / employees> </wmi>

[0052] Em uma modalidade, objetos de domínio de aplicativo são gerados com base nas chaves passadas pelo aplicativo 100 (tal como as chaves <employee> mostradas no exemplo acima). As chaves podem ser mapeadas para segmentos correspondentes XML através de um arquivo de configuração usado pelo configurador 103.

[0053] O analisador StAX 104 extrai o segmento correspondente a cada nome de segmento passado pelo aplicativo 101. XMLBeans 105 gera o objeto XMLBeans correspondente usando o segmento XML extraído. A estrutura 102 executa a validação XSD no objeto XMLBeans gerado; erros de validação são delegados a um manipulador de erro específicas de aplicativo para processamento adicional.

[0054] Em uma modalidade, em caso de falha de validação XSD, o próximo segmento com a mesma chave é obtido pela estrutura 102 (a menos que a estrutura 102 seja configurada para incluir segmentos XML inválidos). Este processo é repetido até que um segmento válido seja encontrado, ou o início do próximo segmento seja detectado ou o documento inteiro XML 107 esteja esgotado.

[0055] Em uma modalidade, a estrutura 102 delega a criação de objetos de dados de aplicativo de objetos XMLBeans à camada de tradução 106. O objeto de dados de aplicativo resultante é retornado ao aplicativo 101.

[0056] Em uma modalidade, o sistema da presente invenção é capaz de processar documentos XML 107 de tamanho arbitrário sem encontrar limitações de memória. O aplicativo 101 é capaz de obter objetos de dados de aplicativo correspondentes aos dados contidos em um segmento sem a inclusão de qualquer um de seus subsegmentos, de modo que o aplicativo 101, em seguida, pode obter dados para cada subsegmento de forma incrementai serial. Em uma modalidade, isto é obtido chamando um método openSegment(), que retorna um caso de classe SegmentCursor. O aplicativo 101 pode obter um objeto de dados correspondente a um determinado segmento, sem a inclusão de quaisquer dados de seus subsegmentos, usando o método getDataObject(). O método next() pode ser usado recursivamente para obter objetos de dados correspondentes a subsegmentos employee em série.

[0057] Com referência agora à Fig. 2A, é mostrado um diagrama de rastreamento de evento representando processamento de um documento XML de acordo com uma modalidade. As etapas específicas representadas na Fig. 2A são meramente exemplares de uma modalidade da presente invenção. O aplicativo 101 envia a localização do documento XML e a chave de configuração à estrutura 102. A estrutura solicita 202 informações de configuração (tal como a estrutura do documento XML) do configurador 103, com base na chave fornecida pelo aplicativo 101.

[0058] Para recuperar esta informação, a estrutura 102 solicita ao configurator 103, a localização do “cabeçalho” do segmento XML que contém as informações “para” e “de”, conforme mostrado no documento XML de exemplo acima. O configurador 103 contém um mapeamento que indica onde podem ser encontradas porções relevantes do documento XML 107; por conseguinte, o configurator 103 responde à solicitação 202 enviando 203 informações de configuração sobre a estrutura XML incluindo, por exemplo, segmentos, subsegmentos, consultas X-Path, classes de tradutor e semelhantes. No exemplo acima, tais informações são encontradas no cabeçalho do documento XML 107.

[0059] O aplicativo 101 solicita o objeto de domínio de aplicativo fornecendo o nome do segmento XML. A estrutura 102 envia 205 uma solicitação ao analisador StAX 104 para extrair o segmento XML. O analisador StAX 104 analisa o documento XML 107 até encontrar as informações identificadas; no exemplo acima ele analisa o documento XML 107 até que a etiqueta “<header>“ é encontrada e informa a estrutura 102 quando a etiqueta é encontrada. A estrutura continua a recuperação do XML via StAX até etiqueta de final “</header>“ ser encontrada.

[0060] Em uma modalidade, essa análise pode envolver repetidas recuperações de dados do armazenamento de dados 108. Uma vez que as informações identificadas são encontradas, o analisador StAX 104 retorna 206 ao segmento XML.

[0061] A estrutura 102, em seguida, envia 207 uma solicitação para a camada de tradução 106 para requisitar conversão para um objeto XMLBeans, por exemplo, passando o segmento XML extraído e o nome do segmento fornecidos pelo aplicativo. Em uma modalidade, a camada de tradução 106 inclui módulo XMLBeans 105 para converter o segmento XML para objetos XMLBeans de acordo com técnicas bem conhecidas. A camada de tradução 106 e/ou o módulo XMLBeans 105 podem estar localizados localmente ou remotamente com relação à estrutura 102 e com relação a outros componentes do sistema 100. A camada de tradução 106 retorna 208 ao objeto correspondente XMLBeans gerado usando o segmento XML e o nome de segmento.

[0062] A estrutura 102, então, envia 209 os objetos XMLBeans para a camada de tradução 106 para conversão em um objeto em um formato que seja compreensível pelo aplicativo 101, passando a camada de tradução 106, o objeto XMLBeans e a chave de segmento. Uma vez que a camada de tradução 106 gerou este objeto de domínio de aplicativo, ela retorna 210 o objeto de domínio de aplicativo, cuja estrutura 102 102, em seguida, retorna 211 ao aplicativo 101 para processamento adicional.

[0063] Em uma modalidade, o configurator 103 controla a manipulação de exceção. Por exemplo, se XML inválido for encontrado, o configurator 103 pode indicar se o XML inválido deve ser ignorado, ou se deve ser feita uma tentativa para recuperar qualquer porção do XML inválido que seja recuperável.

[0064] Com referência agora às Figs. 2B e 2C, é mostrado um diagrama de rastreamento representando o processamento de um documento XML de acordo com outra modalidade, incluindo detalhes adicionais e manipulação de erro.

[0065] O aplicativo 101 solicita 241 que um objeto de domínio de aplicativo para um segmento seja aberto, por exemplo, fornecendo o nome do segmento XML emitindo uma chamada openDataOb-ject(segmentName). A estrutura 102 recebe a chamada e envia uma solicitação ao analisador StAX 104 para extrair 242 um elemento de início e atributos para o segmento, por exemplo, chamando extractStar-tElementAndltsAttributes(segmentName). O analisador StAX 104 retorna 257 ao segmento XML. A estrutura 102, em seguida, acrescenta 243 uma etiqueta de final ao XML extraído, por exemplo chamando appendEndTagInExtractedXml(). O segmento XML extraído se transforma em um XML bem formado após a etiqueta de final ser acrescentada.

[0066] A estrutura 102 solicita 244 um objeto XMLBeans da camada de tradução 106, por exemplo, passando o XML extraído e o nome de segmento para a camada de tradução 106 por meio de uma chamada getXmlObject (extractedXml, segmentName). A camada de tradução 106 gera 245 um objeto XMLBeans correspondente chamando createCor-respondingXmlObject() e retorna 246 o objeto XMLBeans gerado. A estrutura 102 solicita 247 um objeto de domínio de aplicativo, por exemplo, chamando um método generateDataObject(xmlObject). A camada de tradução 106 responde retornando 248 um objeto de domínio de aplicativo.

[0067] A estrutura 102, então, exemplifica 249 um cursor de segmento encapsulando o objeto de domínio de aplicativo, para manter o controle de uma localização dentro de um segmento, por exemplo, chamando um método instantiateSegmentCursor(Object). Este cursor de segmento é retornado 250 ao aplicativo 101. O aplicativo 101 agora pode solicitar objetos de dados em um arranjo de tipo de envio, de modo que o aplicativo 101 está no controle de fluxo de dados.

[0068] O aplicativo 101 solicita 251 um objeto de domínio de aplicativo encapsulado pelo cursor segmento 231, por exemplo, chamando getDataObject(). O cursor de segmento 231 retorna 252 o objeto de domínio de aplicativo solicitado. Conforme necessário, o aplicativo 101, em seguida, solicita 253 um objeto de domínio de aplicativo passando um nome de subsegmento, por exemplo, emitindo uma chamada next(subSegmentName). O cursor de segmento 231 encaminha 254 a solicitação a estrutura 102 fornecendo o nome do atual segmento aberto e seu subsegmento. A estrutura 102 gera 257 um objeto de domínio de aplicativo, seguindo técnicas descritas acima em relação à Fig. 2A. No entanto, em uma modalidade, XML é extraído apenas de dentro do atual segmento aberto. A estrutura 102, em seguida, retorna 255 o objeto de domínio de aplicativo e o cursor de segmento 231 retorna 256 o objeto ao aplicativo 101.

[0069] Continuando com Fig. 2C, o aplicativo 101 solicita 261 um objeto de domínio de aplicativo para o segmento XML, por exemplo, fornecendo o nome do segmento XML por meio de uma chamada getDataObject(segmentName). A estrutura 102 chama 262 o analisador StAX 104 para extrair um segmento XML para o nome de segmento identificado, por exemplo, chamando extractXmlSeg-ment(segmentName). O analisador StAX 104 retorna 274 o segmento XML. A estrutura 102, em seguida, solicita 263 um objeto XMLBeans, por exemplo, passando o XML extraído e o nome de segmento por meio de uma chamada getXmlObject(extractedXml,segmentName) para a camada de tradução 106. A camada de tradução 106 gera 264 um objeto XMLBeans correspondente ao XML extraído, por exemplo, chamando createCorrespondingXmlObject(). A camada de tradução 106 retoma 265 o objeto XMLBeans para a estmtura 102.

[0070] Em uma modalidade, a estmtura 102 valida 266 o objeto XMLBeans contra o XSD, por exemplo, chamando validateAgainstXsdQ. A chamada do método pede ao objeto XMLBeans para validar-se contra o XSD. Se existirem quaisquer erros de validação, a estmtura 102 obtém 267 os mesmos de XMLBeans 105. A estrutura 102 executa 268 um identificador de registro consulta XPath (configurado via Configura-dor) para extrair identificadores de registro para aqueles objetos que possuem erros (mnXPathQueriesToExtractRecordIdentifiers(xml Object)); XMLBeans 105 retorna 275 identificador(es) de registro. A estmtura 102 acrescenta 269 uma sequência de identificador às mensagens de erro, de modo que a fonte do erro pode ser identificada (appendldentifierStringToErrorMessagesQ). A estmtura 102, em segui- da, envia 270 cada mensagem de erro ao manipulador de erro 233, incluindo a identificação do erro e o objeto que o causou, para manipulação no manipulador de erro 233 (handleValidationErrors (code, message)).

[0071] A estrutura 102, em seguida, transmite 271 o objeto XML-Beans e o nome de segmento para a camada de tradução 106 para conversão em um objeto de domínio de aplicativo, por exemplo, emitindo uma chamada generateDataObject(xmlObject). A camada de tradução 106 executa a tradução gerando 272 um objeto de domínio de aplicativo correspondente ao objeto XMLBeans e retorna 273 o objeto de domínio de aplicativo para a estrutura 102 que, então, encaminha 276 o objeto de domínio de aplicativo para o aplicativo 101.

Gerando um documento XML

[0072] Conforme descrito neste documento, a geração de documento XML 107 pode acontecer de forma fragmentada, com o aplicativo 101 fornecendo informações para cada segmento por vez e indicando se o segmento é um segmento completo ou um segmento de encapsula-mento. Certos segmentos podem ser mantidos na memória enquanto o documento XML 107 está sendo gerado, enquanto outros segmentos podem ser grandes demais para manter na memória, de modo que elementos individuais (tais como registros) podem ser gerados e anexados um por um.

[0073] O aplicativo 101 pode precisar gerar um documento XML 107 baseado em dados de qualquer número de fontes de dados, assim como a lógica de negócio do aplicativo. O aplicativo 101 tem, portanto, os dados encapsulados em objetos de dados de aplicativo; conforme descrito neste documento, estes objetos de dados de aplicativo são usados para produzir um segmento XML. O sistema da presente invenção permite que essa transformação ocorra sem exigir que o aplicativo 101 tenha qualquer conhecimento ou consciência do analisa- dor StAX 104 ou XMLBeans 105. Objetos de dados são passados incrementalmente para a estrutura 102, de modo que segmentos XML correspondentes possam ser gerados e anexados ao documento XML 107 sendo gerado.

[0074] A estrutura 102 começa a produzir código XML em seu buffer de memória com base nos objetos de dados fornecidos pelo aplicativo 101. O processo continua com dados no buffer sendo gravados no armazenamento de dados 108 quando o buffer de memória está cheio.

[0075] Conforme descrito acima, a camada de tradução 106 fornece o mapeamento entre objetos de dados do aplicativo e objetos XMLBeans correspondentes. A estrutura 102 delega a tarefa de gerar os objetos XMLBeans à camada de tradução 106. A estrutura 102 executa validação nos objetos XMLBeans gerados pela camada de tradução 106 contra a definição de esquema XML (XSD) e delega a manipulação de mensagens de erro de validação a um manipulador de erro de aplicativo. A estrutura 102 usa o objeto XMLBeans para gerar um segmento XML correspondente e grava o segmento em seu buffer. Em uma modalidade, este buffer pode ser salvo para um dispositivo de armazenamento de dados mais persistente. Uma vez que o aplicativo 101 indica o final do processo de geração de XML, o buffer é liberado e o arquivo é fechado.

[0076] Em muitas situações, um grande número de registros deve ser gravado. Desde que o segmento XML e objetos XMLBeans correspondentes são gerados na memória, pode haver limitações de recursos se a estrutura 102 fosse tentar manter todos os registros na memória ao mesmo tempo. Nesse sentido, as técnicas da presente invenção fornecem um mecanismo pelo qual os elementos em um segmento podem ser adicionados incrementalmente. O aplicativo 101 pede à estrutura 102 para adicionar um segmento cujos segmentos filhos (subsegmentos) serão adicionados de forma incrementai. A estrutura 102 remove a etiqueta de final de segmento (por exemplo, </employees>) do XML gerado e empurra-o para uma pilha. O aplicativo 101, em seguida, pode continuar a adicionar subsegmentos de empregado incrementalmente. Depois que o aplicativo 101 tiver terminado de adicionar todos os subsegmentos, a última etiqueta da pilha é rolada e anexada de volta no código XML gerado. Esta geração incrementai de XML permite que os documentos XML de tamanho arbitrário sejam gerados sem encontrar limitações de memória.

[0077] Subsegmentos podem ser aninhados um com outro conforme desejado. A estrutura 102 não impõe quaisquer restrições sobre a profundidade da hierarquia. Em uma modalidade, é responsabilidade do aplicativo 101 informar a estrutura 102 quando para abrir um segmento e quando fechá-lo.

[0078] Por exemplo, ao gerar o código XML mostrado acima, o segmento <header> é gerado juntamente com o segmento <employees> e dados associados e englobando <wmi> tag. Para gerar e gravar o segmento <header>, o sistema abre a etiqueta <wmi> englobada e grava o segmento <header>. A etiqueta final </wmi> ainda não pode ser gravada porque dados adicionais (o segmento <employees>) ainda precisam ser gravados primeiro. Por conseguinte, o documento XML 107 temporariamente será não bem formado, desde que faltará nele a etiqueta final </wmi>. Esta etiqueta final pode ser retida de modo que ele possa ser gravada no momento apropriado.

[0079] Em uma modalidade se o aplicativo 101 estiver tentando gravar um segmento de documento XML 107 sem gravar todo o documento 107, ele pode passar uma chamada openSegment(), para informar a estrutura 102 que o segmento deve ser aberto, mas ainda não fechado, e que apenas uma porção dos dados está sendo enviada com mais a seguir mais tarde. Isto permite gravação incrementai de elemen- tos de dados (tal como registros). A etiqueta final pode ser obtida do analisador StAX 104 e retida na memória para que ela possa ser gravada após os elementos de dados serem todos gravados.

[0080] Com referência agora às Figs. 3A e 3B, é mostrado um diagrama de rastreamento de evento representando a geração de documento XML 107 de acordo com uma modalidade. O aplicativo 101 envia 321 uma configuração chave para a estrutura 102 que solicita 322 do configurador 103 a configuração para a chave fornecida. O configurador 103 retorna 323 as informações de configuração solicitadas, incluindo dados sobre a classe de tradutor, se ignorar ou incluir segmentos XML inválidos e assim por diante.

[0081] O aplicativo 101 passes 301 um objeto de domínio de aplicativo para a estrutura 102, solicitando que o objeto seja convertido em XML. A estrutura 102 envia 302 o objeto para a camada de tradução 106, por exemplo, emitindo uma chamada generateXmlObject(). A tradução posterior 106 executa um método tal como createCorrespon-dingXmlObject() e retorna 303 um objeto XMLBeans correspondente. A estrutura 102, em seguida, gera 304 um segmento XML do objeto XMLBeans, por exemplo, usando classes XMLObject geradas usando XSD. A estrutura 102 grava 309 o XML para o armazenamento de dados 108, da seguinte maneira.

[0082] Com referência agora à Fig. 3B, o aplicativo 101 envia 306 uma chamada openSegment(object) para a estrutura 102. Esta chamada diz a estrutura 102 para abrir um novo segmento para dados a serem gravados, mas para não gravar uma etiqueta de final. A estrutura 102 envia 324 o objeto de domínio de aplicativo para a camada de tradução 106, por exemplo, emitindo uma chamada generateXmlOb-ject(). A tradução mais tarde 106 retorna 325 um objeto correspondente XMLBeans. A estrutura 102, em seguida, gera 326 um segmento XML correspondente do objeto XMLBeans, por exemplo, usando classes XMLObjects geradas usando XSDs.

[0083] A estrutura 102 envia 307 o XML ao analisador StAX 104 para análise, de modo a obter a etiqueta de final. O analisador StAX 104 analisa o XML para identificar a etiqueta de final e envia 308 a etiqueta de final para a estrutura 102. Em uma modalidade, a etapa 307 é implementada usando uma chamada removeSegmentEndTagAn-dPushItInStack(), que faz com que a etiqueta de final seja removida. A estrutura 102 retém a etiqueta de final em uma pilha FIFO de memória para uso posterior, por exemplo, salvando a etiqueta de final em uma pilha. Em alguns casos, podem ser salvas múltiplas etiquetas de final dessa maneira. O código XML, sem a etiqueta de final, é acrescentado 311 aos dados no armazenamento de dados 108. Usando esta técnica, a estrutura 102 é capaz de gravar o código XML de modo parcial, permitindo que o código XML de qualquer comprimento arbitrário seja gravado sem correr contra as limitações de memória. Em uma modalidade, isto é implementado usando uma chamada writeXmlToBuffer-BackedByFile(), que faz com que o código XML seja gravado em um buffer que é também apoiado para armazenamento persistente.

[0084] Para cada segmento a ser adicionado, o aplicativo 101 envia 310 uma chamada addSegment() para a estrutura 102. Ela permite a adição de um número arbitrário de subsegmentos ao segmento aberto atualmente. A estrutura 102 envia 329 o objeto de domínio de aplicativo para a camada de tradução 106, por exemplo, emitindo uma chamada generateXmlObject(), que invoca um método createCorrespondingXmlO-bject() e retorna 330 um objeto correspondente XMLBeans.

Opcionalmente, a estrutura 102 pode validar o objeto retornado XMLBeans contra o XSD. Se quaisquer mensagens de erro são retornadas, a estrutura 102 solicita identificadores de gravação da camada de tradução 106, por exemplo, emitindo uma chamada getRecordldentifi-ers(). A camada de tradução 106 retorna uma sequência de identificador extraída do objeto de dados de aplicativo. A camada de tradução 106 é responsável pela extração e geração de um identificador de gravação significativo. A estrutura 102 acrescenta sequência de identificador às mensagens de erro para que gravações apropriadas que causaram o erro possam ser identificadas; por exemplo, essa operação pode ser executada por uma chamada appendldentifierStringToErrorMessagesQ. Se necessário, um manipulador de erro pode ser invocado por meio de uma chamada handleValidationErrors().

[0086] A estrutura 102 gera 331 o segmento correspondente XML usando o objeto XMLBeans 330 usando, por exemplo, classes XMLOb-ject geradas usando XSDs.

[0087] A estrutura 102 acrescenta 333 o segmento XML de acordo com as instruções recebidas do aplicativo 101.

[0088] As Etapas 310 e 329 através de 333 são repetidas para cada segmento sendo adicionado.

[0089] Uma vez que todos os dados foram adicionados ao documentos XML 107, a estrutura 102 está pronta para fechar o segmento aberto envolvente (se existir algum) e anexar quaisquer outras etiquetas de final conforme necessário para corretamente terminar a gravação do documento. O aplicativo 101 envia 315 uma chamada closeSegment() que faz com que a estrutura 102 abra 312 a etiqueta de final da pilha na memória para o segmento cujos subsegmentos estavam sendo gravados incrementalmente e acrescente a etiqueta de final aos dados serem gravados no armazenamento de dados 108. Em uma modalidade, a etapa 312 pode ser executada chamando um método popSta-ckAndWritePoppedEndTagToBufferBackedByFile().

[0090] O aplicativo 101, em seguida, envia 313 uma chamada closeAll() que faz com que a estrutura 102 recupere todas as restantes etiquetas de fechamento da pilha e acrescente-as ao documento XML 107. Por exemplo, se as etiquetas foram salvas em uma pilha, a estrutura 102 abre 314 as etiquetas da pilha e acrescenta-as aos dados sendo gravados no armazenamento de dados 108. Desta forma, as etiquetas são gravadas na ordem correta. O resultado é um documento XML bem formado 107 no armazenamento de dados 108. Em uma modalidade, as etapas 313 e 314 podem ser executadas, chamando um método de popStackUntilEmptyAndWritePoppedEndTagsToBuffer-BackedByFile(), seguido por um método de flushBuffer() e um método closeFile().

Convertendo um documento XML para um arquivo simples [0091] Como mencionado acima, em uma modalidade, o sistema da presente invenção também é capaz de realizar conversões de documentos de vários tipos. Por exemplo, às vezes é útil converter documentos XML em arquivos simples. Arquivos simples são arquivos de dados que contém registros sem nenhum relacionamento estruturado. Eles podem ser usados, por exemplo, para carregamento em bruto de arquivos de dados quando operam em conexão com componentes (como o SQL* Loader) que pode não ser capaz de carregar XML. Carregadores em bruto geralmente tomam entradas de um arquivo simples e usam algum conhecimento adicional para interpretá-los. Por exemplo, Oracle SQL* Loader usa arquivos de controle para fornecer informações adicionais sobre as propriedades de formato de arquivo.

[0092] Em geral, um arquivo simples pode assumir qualquer forma. Um arranjo típico para um arquivo simples inclui as seguintes seções: - Dados de cabeçalho: inclui, por exemplo, metadados, incluindo identificador remetente, identificador de transação, data de recebimento e afins. Geralmente inclui informações que não precisam ser repetidas em cada registro de corpo. - Dados de corpo: inclui registros individuais, tal como registros de empregados. - Dados de rodapé: retêm itens para resumir os dados no arquivo, tal como o número total de registros e semelhantes.

[0093] Em uma modalidade, o sistema da presente invenção fornece um mecanismo para transformar documentos XML 107 em arquivos simples. Um arquivo de configuração, conhecido como StaxBeanMapping.properties fornece informações quanto a onde vários itens de dados devem ser colocados no arquivo simples. Desta forma, dados a serem populados nas seções de cabeçalho, corpo e/ou rodapé podem ser especificados, por exemplo, através da linguagem XPath query. XPath pode se referir a objetos XML correspondentes a segmentos, subsegmentos e/ou abrir segmentos. Dessa maneira, uso de memória é otimizado, uma vez que apenas o segmento correspondente do XML e/ou do objeto XMLBeans precisa estar na memória em um determinado momento. Não é necessário reter o documento inteiro XML na memória. Se houver uma necessidade de cruzar dados de um segmento para outro, a estrutura 102 fornece a configuração de tais referências cruzadas, especificada como XPath references, de modo que os dados apropriados podem ser retidos na memória durante a transformação.

[0094] Qualquer tipo de delimitadores de campo e delimitadores de registros pode ser usado para separar os campos entre si e separar registros entre si. Por exemplo, tabulações ou vírgulas podem ser usadas como delimitadores de campo e quebras de linha (retornos de carro) podem ser usadas como delimitadores de registros, para que cada linha do arquivo simples corresponda a um registro.

[0095] Em uma modalidade, o arquivo simples é definido por uma configuração que especifica a sintaxe para o arquivo. Por exemplo, a configuração pode especificar a ordem na qual os dados de corpo devem aparecer e todos os metadados adicionais que devem ser incluídos (tal como o número total de registros, por exemplo).

[0096] Um exemplo de um documento XML 107 que pode ser convertido em um arquivo simples de acordo com técnicas descritas aqui é o seguinte: <wmi> <header> </header> <employees> <employee> <employee> < / employees> <departments> <department> <department> < / departments> </wmi>

[0097] Pode ser útil em algumas situações, enriquecer o arquivo simples com dados específicos do aplicativo que não eram parte do documento XML 107. Em uma modalidade, a estrutura 102 fornece suporte para a adição desses dados ao arquivo simples transformado. Esses dados podem ser especificados pela configuração e podem incluir, por exemplo, dados que podem ser extraídos, derivados ou calculados a partir do XML. Esses dados podem incluir, por exemplo: - Itens de dados do segmento atualmente sendo processado: estes podem ser especificados, por exemplo, usando um segmento XPath. - Itens de dados que podem ser necessários, mas não disponíveis para o segmento atualmente sendo processado; estes podem ser especificados, por exemplo, usando um XPath de referência cruzada. - Em uma modalidade, o tipo de referência cruzada XPath é especificado no arquivo de configuração que indica a estrutura que é representada em valor pela consulta XPath deve ser guardado na memória e deve ser atribuído um codinome. Os dados correspondentes ao XPath podem ser acessados posteriormente consultando o codinome correspondente. Por exemplo, o valor de XPath query header/@senderID (extraído do segmento de cabeçalho) pode ser atribuído um codinome de referência cruzada “senderlD” que pode ser usado por outros segmentos para incluir o valor correspondente ao XPath header/@senderID. Em uma modalidade, todos os codinomes cruzados são salvos na memória, tão logo o segmento ao qual eles pertencem é processado. - Em uma modalidade, os dados de referência cruzada podem incluir dados globais com base em uma fórmula que é acumulada ao longo do tempo e podem representar uma combinação de dados de vários segmentos. - Em uma modalidade, os dados de referência cruzada podem incluir dados de registro por registro que são mantidos por algum período de tempo e, em seguida, eliminados quando usados. - Itens de dados derivados: estes podem incluir qualquer coisa que é derivada de um ou mais segmentos. Um exemplo é uma contagem de registros, que mantém o rastreamento de quantos registros foram processados. Por exemplo, a estrutura 102 pode manter uma contagem de registros de empregados (subsegmentos) em cada segmento aberto enquanto extraindo cada registro de empregado e gravando-o no arquivo simples. A contagem pode ser gravada como parte do registro de empregado no arquivo. Além disso, ela pode ser gravada em uma seção de rodapé do arquivo. - Itens de dados de sessão: estes podem incluir quaisquer dados que o aplicativo 101 desejar acrescentar, mas que não estão disponíveis no XML. Por exemplo, se uma fonte parceira fornece um arquivo de inventário, o nome do arquivo pode ser passado para o sistema e um identificador de arquivo pode ser retornado. Esse identificador de arquivo não pode ser retirado do XML, mas pode ser um dado útil a ser adicionado ao arquivo simples. Nesse sentido, esses dados podem ser incluídos nesta categoria. Outros exemplos incluem a ID de registo, hora do processamento e afins. - Dados de Aplicativo: o aplicativo 101 pode adicionar qualquer número de pares nome-valor durante o tempo de execução. Esses valores podem ser referenciados por seus nomes e podem ser adicionados em qualquer/quaisquer seção(ões) do arquivo transformado como desejado.

[0098] Com referência agora às Figs. 4A e 4B, é mostrado um diagrama de rastreamento de evento representando um método para converter um documento XML 107 em um arquivo simples de acordo com uma modalidade.

[0099] O aplicativo 101 chama a estrutura 102 para iniciar a conversão de XML em arquivo simples enviando 402 a estrutura 102 o local de arquivo e a chave de configuração. Em uma modalidade, isso é feito pelo aplicativo 101 enviando uma chamada createlnstance (String key, FileinputFile) à estrutura 102.

[0097] A estrutura 102 solicita 403 ao configurador 103 a configura- ção associada à chave. Em resposta, o configurador 103 envia 404 a configuração para a estrutura 102. Tendo recebido a configuração, a estrutura 102 agora sabe quais elementos do arquivo XML usar para as várias partes de arquivo simples, incluindo cabeçalho, corpo, rodapé, delimitadores e assim por diante.

[0098] A chave enviada pelo aplicativo 101 identifica, portanto, uma configuração que é, em uma modalidade, exclusiva para o tipo de XML que está sendo processado. As informações contidas no arquivo de configuração e identificadas por meio de chave contêm informações como: • Classe de tradutor; • Estrutura de XML, tal como segmentos e subsegmentos; • Se pular ou incluir registros inválidos; e • Se realizar validação XSD.

[0099] Em uma modalidade, a configuração especifica a estrutura de arquivo simples, incluindo informações como a ordem em que dados de mensagem devem aparecer e todos os metadados adicionais que devem ser incluídos. Em uma modalidade, a configuração pode ser especificada como uma classe Java, embora possa ser usado qualquer formato desejado.

[00100] O aplicativo 101, então, solicita 431 que uma transformação seja executada no documento XML especificado.

[00101] A estrutura 102 chama o analisador StAX 104, abastecendo-o com o local de arquivo de modo que o analisador StAX 104 possa começar analisando o arquivo para extrair o segmento XML. A estrutura 102 solicita dados específicos do analisador StAX 104, tais como o segmento XML para o cabeçalho e/ou em outros segmentos XML. Em resposta, o analisador StAX 104 analisa a porção relevante do docu- mento XML 107 para obter os segmentos XML e retorna este XML para a estrutura 102. Por exemplo, para o segmento de cabeçalho, a estrutura 102 pode executar estas etapas chamando extractXmlSeg-ment(headerSegment).

[00102] Em uma modalidade, é gerado um registro de cabeçalho de arquivo simples extraindo o segmento correspondente, configurado no arquivo de configuração, a partir dos dados XML. Quaisquer codinomes de referências cruzadas globais configuradas também são extraídos se encontrados no segmento.

[00103] A estrutura 102 chama 411 o analisador StAX 104 para extrair o segmento necessário para gerar o registro de cabeçalho do arquivo simples. A estrutura 102 obtém o nome do segmento do confi-gurador 103 e passa-o para o analisador StAX 104 para obter o segmento XML correspondente. O analisador StAX 104 retorna 41 IA o segmento XML requerido para o registro de cabeçalho.

[00104] A estrutura 102 passa 411B o segmento XML extraído e o nome do segmento para a camada de tradução 106. A camada de tradução gera 411C um objeto correspondente XMLBeans e retorna-o 411D para a estrutura 102.

[00105] A estrutura 102 executa 411E as consultas XPath configuradas no objeto XMLBeans. Ela também executa consultas XPath para codinomes de referências cruzadas configurados e os armazena na memória para uso posterior.

[00106] A estrutura 102 monta o registro de cabeçalho e grava-o 412 no arquivo simples sendo gerado no armazenamento de dados 108.

[00107] Quaisquer dados globais, dados de referência cruzada ou similares podem ser armazenados (por exemplo em um codinome) de modo que eles podem ser disponibilizados para uso com outros registros.

[00108] A estrutura 102 processa segmentos cujos subsegmentos representam um registro no corpo do arquivo simples transformado. A Fig. 4B representa detalhes adicionais sobre as etapas específicas envolvidas na gravação do arquivo simples. De acordo com o método mostrado na Fig. 4B, a estrutura 102 é capaz de manter dados na memória quando tais dados podem ser necessários para gravar registros no arquivo simples.

[00109] A estrutura 102 pede ao analisador StAX 104 para fornecer o segmento XML correspondente a cada nome de segmento. Em uma modalidade, a estrutura 102 obtém somente o segmento XML que representa o elemento de início e atributos associados. Assim, a estrutura 102 solicita 421 um segmento XML, elemento de início e seus atributos do analisador StAX 104 configurado para o corpo do arquivo simples a ser gravado. O analisador StAX 104 retorna 422 o XML solicitado. A estrutura 102 acrescenta 422A uma etiqueta de final ao XML extraído, para gerar um XML bem formado.

[00110] A estrutura 102, então, faz um loop através de um processo de extração de segmentos e subsegmentos no documento XML 107 e gravando o registro correspondente no arquivo simples. Para cada segmento e subsegmento, a estrutura 102 solicita extração do subseg-mento pelo analisador StAX 104 e o analisador StAX 104 retorna o segmento XML para o segmento ou subsegmento especificado. Cada subsegmento pode se referir a uma entidade específica, tal como um empregado ou similar.

[00111] Detalhes adicionais são mostrados na Fig. 4B. A estrutura 102 solicita 422B um objeto XMLBeans, por exemplo, passando o XML extraído e nome de segmento para a camada de tradução 106. A camada de tradução 106 gera 422C um objeto XMLBeans correspondente e retorna 422D o objeto XMLBeans para a estrutura 102. A estrutura 102 extrai 422E dados do objeto XMLBeans para geração de um arquivo simples, por exemplo, executando consultas Xpath configuradas no nível do segmento.

[00112] A estrutura 102 extrai subsegmentos XML do segmento atual um por um passando o nome de cada subsegmento para o analisador StAX 104. Para cada subsegmento, a estrutura 102 solicita 424 extração do subsegmento pelo analisador StAX 104 e o analisador StAX 104 retorna 425 o segmento XML para o subsegmento especificado. A estrutura 102 solicita 425A um objeto XMLBeans, por exemplo, passando o XML extraído e o nome de subsegmento para a camada de tradução 106. A camada de conversão 106 gera 425B um objeto correspondente XMLBeans e retorna 425C o objeto XMLBeans para a estrutura 102. A estrutura 102 extrai 425 D dados do objeto XMLBeans para geração de um arquivo simples, por exemplo, executando consultas Xpath configuradas no nível do subsegmento. A estrutura 102 também pode usar dados globais extraídos anteriormente e/ou dados fornecidos pelo aplicativo para montar o registro.

[00113] A estrutura 102, então, monta 425E um registro de corpo usando os dados coletados de várias fontes e grava 429 o registro no armazenamento de dados 108 como um arquivo simples.

[00114] As etapas 421 a 429 podem ser repetidas quantas vezes forem necessárias até que todos os registros sejam gravados. Em uma modalidade, a estrutura 102 faz um loop pelos vários segmentos de corpo no arquivo. Cada segmento de corpo pode conter qualquer número de subsegmentos e a estrutura 102 faz um loop através deles também.

[00115] Uma vez que todos os segmentos são feitos, a estrutura 102 monta 429A um registro de rodapé e grava 429B o registro de rodapé no armazenamento de dados 108, acrescentando-o ao arquivo simples. A estrutura 102, então, fecha 429C o arquivo.

[00116] Assim, para cada segmento de corpo, a estrutura 102 pode executar as seguintes etapas: • Extrair o elemento de início do corpo e seus atributos (extractStartElementAndltsAttributes(segmentName). • Acrescentar uma etiqueta de final (appendEndTagl-nExtractedXml()). • Solicitar a conversão para objeto XMLBeans (enviando getXmlObject (extractedXml, segmentName) para a camada de tradução 106 que executa createCorrespondingXmlObject() e retorna o objeto XMLBeans). • Extrair dados do objeto XMLBeans (runXPathQuerie-sOnXmlObject()).

[00117] Em seguida, para cada subsegmento no segmento de corpo, a estrutura 102 pode executar as seguintes etapas: • Extrair o XML correspondente para o subsegmento. • Solicitar a conversão para o objeto XMLBeans (enviando getXmlObject (extractedXml, subSegmentName) para a camada de tradução 106 que executa createCorrespondingXmlObject() e retorna o objeto XMLBeans. • Extrair dados do objeto XMLBeans (runXPathQuerie-sOnXmlObject()). • Gravar os dados extraídos do arquivo simples (write-ExtractedDataInFile()).

[00118] Uma vez que todos os subsegmentos em todos os segmentos de corpo foram processados, a estrutura 102 grava o rodapé (writeFoo-terDataInFile()) e fecha o arquivo (closeFile()).

[00119] Em uma modalidade, pode ser útil para a estrutura 102 manter rastreamento de dados globais, tal como o número total de registros processados. Tais informações podem ser utilizadas, por exemplo, para inclusão em um rodapé ou outro elemento de dados do arquivo simples sendo gravado. Em tal situação, o aplicativo 101 pode emitir uma chamada, tal como addSessionData (chaves, dados), para a estrutura 102. Dados incluídos na chamada, em seguida, podem ser armazenados e usados pela estrutura 102 conforme apropriado. Exemplos de tais chamadas: • addSessionData (“reglD”, 36590); • addSessionData (“timeProcessed”, “25 de julho de 2009”) [00120] A estrutura 102, em seguida, pode usar os dados de sessão fornecidos pelo aplicativo durante a gravação de registros no arquivo simples. Em uma modalidade, os dados de sessão serão apenas gravados em um registro (corpo, cabeçalho ou rodapé) se a estrutura 102 é configurada para fazê-lo.

Arquitetura da estrutura [00121] As técnicas descritas acima podem ser implementadas usando diversas modalidades de módulos de software. A seguir é um exemplo de uma arquitetura para a estrutura 102 que fornece uma grande variedade de opções de configuração. Em uma modalidade, um conjunto de classes de produtor e tradutor é configurado em um arquivo de configuração acessível ao configurador 103. Conforme descrito acima, o aplicativo 101 passa o nome da chave da classe de tradutor a ser usado. A estrutura 102, em seguida, executa a tarefa necessária, usando a camada de tradução 106 e o arquivo de configuração especificado. Em uma modalidade, são fornecidas pelo menos três classes: uma classe de produtor para gerar documentos XML 107, uma classe de consumidor para processar documentos XML 107 para gerar objetos de domínio de aplicativo utilizáveis pelo aplicativo 101 e uma classe de transformador para transformar documentos XML 107 para outro formato, tal como um formato de arquivo simples. A seguir estão alguns exemplos de detalhes dessas classes.

Classe de Produtor [00122] Com referência agora à Fig. 7, é mostrado um diagrama de classes para uma classe de produtor 700 de acordo com uma modalidade. Nesta arquitetura, ErrorHandler 701, XmlProducer 703, 704 XmlProducerFactory e XmlException 708 são expostos ao aplicativo 101.

[00123] A classe de configurator 709 implementa o configurator 103 que é responsável por carregar, analisar, validar e cache da configuração fornecida no arquivo de configuração. O configurador 103 exemplifica um exemplo de XmlProducerlmpl, ajusta parâmetros de configuração e injeta um exemplo de classe de tradutor (conforme configurado). XmlProducerFactory 704 delega a criação de XmlProducerlmpl para a classe de configurator 709. Em uma modalidade, a estrutura 102 usa a configuração a seguir para gerar um XML: classes.keys=<list-of-translator-keys> <translator-key>.class=<fully-qualified-translator-class> <translator-key>.includeInvalid=<true | false> <translator-key>.logínvalid=<true | false> • entradas classes.keys são usadas para especificar o nome de todas as chaves sendo usadas no arquivo de configuração. Estas são as chaves para classes de tradutor e todas as outras classes necessárias para produzir, consumir e/ou transformar e arquivo XML em um arquivo simples. Em uma modalidade, cada tipo XML (dirigido por XSD) tem uma chave única e uma configuração exclusiva. A mesma chave é usada pelo aplicativo 101 para obter um exemplo de XmlProdu-cer 703. • a entrada <translator-key>.class especifica o nome totalmente qualificado (com o nome de pacote) da classe de tradutor implementando a interface ProducerTranslator 702. O aplicativo 101 passa o nome da chave para obter uma referência para o exemplo XmlProducer 703. • a entrada <translator-key>.includeInvalid é usada pela estrutura 102 para decidir se ou não os segmentos XML que falham na validação XSD devem ser incluídos no conjunto de resultados. É uma entrada opcional com o valor padrão de verdadeiro. • a entrada <translator-key>.logInvalid é usada pela estrutura 102 para decidir se ou não os segmentos XML que falham na validação XSD devem ser registrados e/ou passados para o manipulador de erro. É uma entrada opcional com o valor padrão de verdadeiro.

[0127] XmlProducer interface 703 inclui operações necessárias para produzir um documento XML 107. O aplicativo 101 usa XmlProducer interface 703 para gerar segmentos XML de forma incrementai. O aplicativo 101 passa objetos de dados de aplicativo; XmlProducer interface 703 produz o XML com a ajuda das classes de tradutor e objeto XML. Em uma modalidade, XmlProducer interface 703 inclui os seguintes métodos: • voidopenSegment(Object object): o aplicativo 101 usa este método para abrir um elemento XML de modo que filhos deste possam ser adicionados incrementalmente. ProducerTranslator interface 702 é implementada pela camada de tradução 106 que usa o objeto de dados passado no aplicativo para criar um objeto XMLBeans equivalente. • booleanaddSegment (Objectobject): o aplicativo 101 usa este método para adicionar um segmento XML ao XML sendo produzido. ProducerTranslator 702 usa o objeto passado para criar objeto XMLBeans equivalente. Em uma modalidade, o segmento XML será anexado como um elemento filho ao último segmento aberto, se houver. Caso contrário, ele será adicionado como um filho da raiz do documento. O valor de retorno é verdadeiro se o segmento passar na validação XSD; caso contrário ele é falso. Em uma modalidade, a validação XSD é executada apenas se estrutura 102 for ou configurada para excluir segmentos inválidos ou configurada para registrar segmentos inválidos. • voidsetErrorHandler (ErrorHandler handler): o aplicativo 101 pode, opcionalmente, ajustar um manipulador de erro que implementa uma interface ErrorHandler. Erros de validação XSD são delegados ao manipulador e o aplicativo 101 pode usá-los de qualquer forma. Erros de validação são registrados usando um registrador Java se nenhum manipulador de erro for definido. • voidcloseSegment (): o aplicativo 101 usa este método para informar a estrutura 102 que adição incrementai de todos os filhos do segmento aberto atualmente está terminada. A estrutura 102 insere a etiqueta de final do último segmento aberto. • voidcloseAll(): o aplicativo 101 usa este método para informar a estrutura 102 que ele não tem mais dados e a geração de XML está concluída. O aplicativo 101 chama este método de modo que o XML pode ser gerado corretamente. A estrutura 102 executa as seguintes operações como resultado desta chamada: • Fecha todos os segmentos abertos inserindo elementos de final correspondentes no XML. Este recurso é útil quando o aplicativo 101 abriu múltiplos segmentos aninhados e deseja fechar todos eles. • Libera o buffer e fecha o arquivo de saída.

[0128] XmlProducerFactory class 704 encapsula a criação de objetos implementando a interface XmlProducer. Em uma modalidade, esta classe inclui dois métodos sobrecarregados para criar objetos - um com o objeto de arquivo e outro com o nome do arquivo para gravar o XML gerado.

[0129] XmlException class 708 é usada para exceções. A estrutura 102 converte exceções encontradas em um exemplo de XmlException class 708. Esta exceção quebra a exceção original de modo que nenhuma informação na exceção original é perdida.

[0130] ProducerTranslator interface 702 define o contrato entre a estrutura 102 e as classes de produtor e tradutor na camada de tradução 106. As classes de tradutor fornecem mapeamento de objeto de dados de aplicativo ao objeto XMLBeans equivalente. Em uma modalidade, ProducerTranslator interface 702 inclui os seguintes métodos: • XmlObjectgetRootObject{): a classe de tradutor deve retornar o exemplo XMLObject do documento raiz de modo que a estrutura 102 possa começar a gerar o documento raiz juntamente com espaços de nome aplicáveis. • XmlObjectgetXmlObject (ObjectdataObject): A classe de tradutor deve gerar o exemplo correspondente XMLBeans baseado no objeto de dados passado no aplicativo. O objeto XMLBeans gerado (XmlObject) é usado pela estrutura para gerar um segmento correspondente de XML. • XmlObject getInnerXmlObject(Object dataObject, XmlObject object): A classe de tradutor tem o conhecimento do objeto de dados de aplicativo, bem como o XMLObject correspon- dente. Dependendo da maneira como tipos de dados são definidos no XSD, ao gerar o objeto XMLBeans do objeto de dados, um objeto XMLBeans pai pode ser gerado no gráfico de objeto XML. Por exemplo, para gerar um objeto XMLBeans de um registro único de empregado, o EmployeesX-MLObject é primeiro exemplificado, seguido por uma matriz de tamanho um contendo Employee XmlObject: esta matriz é adicionada ao objeto embrulhado. Essencialmente, é o Employees XmlObject embrulhando o Employee XmlObject. Para executar uma validação XSD no employee XmlObject, a estrutura 102 extrai o employee XmlObject do XmlObject Employees de embrulho. A classe de tradutor retorna o XmlObject interno que corresponde ao objeto de dados de aplicativo. O XmlObject retornado é usado pela estrutura para executar a validação XSD. • String getObjectldentifiers (ObjectdataObject): mensagens de erro de validação XSD podem variar de analisador para analisador. Pode ser muito difícil para pessoas não técnicas entendê-las. Estas mensagens de erro podem não fornecer informações suficientes para identificar o registro que falhou na validação XSD. Em uma modalidade, a estrutura 102 usa getObjectldentifiers para acrescentar informações adicionais nas mensagens de erro XSD. Em uma modalidade, é a classe de tradutor que determina a informação a ser anexada. O objeto de dados de aplicativo é passado de volta para a classe de tradução para que ela possa extrair as informações apropriadas. As informações extraídas são acrescentadas às mensagens de erro de validação XSD. O objeto de dados de aplicativo é passado para a classe de tradutor, pois ela é a fonte de informação para gerar segmento XML correspondente. A estrutura 102 faz uso desta função quando configurada para registrar erros de validação XSD.

[0131] XmlProducerlmpl class 707 implementa a interface XmlProducer. Um novo exemplo desta classe é retornado ao aplicativo 101 através de XmlProducerFactory. O aplicativo 101 opera no exemplo de XmlProducer para produzir XML incrementalmente invocando métodos fornecidos no contrato de interface XmlProducer. Em uma modalidade, toda a coordenação entre analisador StAX 104, objetos XMLBeans gerados, camada de tradução 106 e manipulação de mensagem de validação é controlada por XmlProducerlmpl class 707. Ela contém todas as funcionalidades necessárias para produzir XML incrementalmente tais como: • Produzir segmentos XML e abrir segmentos correspondentes para objetos de dados do aplicativo fornecidos. • Gravar segmentos XML em um arquivo. • Rastrear todos os segmentos aberts e sua ordem. • Executar validações XSD em segmentos XML e delegar mensagens de erro de validação para um manipulador de erro específico do aplicativo.

[0132] Em adição a implementar os métodos de interface, XmlProducerlmpl class 707 pode também incluir métodos internos, tal como: • protected void setup(File xmlOutFile, ProducerTranslator producerTranslator, boolean includelnvalid, boolean logln-valid): Configurator class 709 cria um novo exemplo desta classe quando o aplicativo 101 solicita um exemplo de XmlProducer via XmlProducerFactory. O configurador 103, em seguida, cria um exemplo da classe de tradutor conforme configurada e invoca este método para passar informações de configuração (por exemplo, se a validação XSD precisa ser executada, se registrar erros de validação XSD e o exemplo de classe de tradutor). • private void startDocument(): Este método é responsável por gerar o nó do documento raiz baseado no correspondente XMLObject retornado pelo método de tradutor getRootObject(). XML é extraído a do XMLObject e passado para o analisador StAX 104. O elemento de extremidade do documento raiz é empurrado para uma fila FIFO (First-In-First-Out). O elemento é exibido e anexado ao XML gerado uma vez que o aplicativo 101 está concluído adicionando todos os segmentos e segmentos abertos. • private boolean analyze(Object dataObject, XmlObject xmlObject): a estrutura 102 usa este método para executar a validação XSD e para registrar quaisquer erros XSD, se configurada para fazê-lo. Ela primeiramente solicita a classe de tradutor para fornecer o XMLObject interno e executa a validação XSD no objeto retornado interno. Ela, em seguida, chama o método getObjectIdentifiers(data Object) na classe de tradutor para obter as informações adicionais a serem anexadas às mensagens de erro de validação XSD. Finalmente, a mensagem de erro é entregue a uma implementação fornecida pelo aplicativo de ErrorHandler para processamento adicional.

[0133] SegmentFilter class 705 implementa uma interface javax.xml.stream.events.EventFilter para filtrar elementos de documento de início e fim dos segmentos XML gerados do XMLObject não raiz. Ela é usada por XmlProducerlmpl 707 para filtrar estes elementos ao analisar o XML usando analisador StAX 104.

Classe de Consumidor [0134] Com referência agora a Fig. 8, é mostrado um diagrama de classe para uma classe de consumidor 800 de acordo com uma modalidade. Nesta arquitetura, XmlConsumer 812, XmlConsumerFac-tory 811, and SegmentCursor 806 são expostos ao aplicativo 101.

[0135] Em uma modalidade, a classe de consumidor 800 lida com duas tarefas: geração de objetos de dados de aplicativo e transformação XML em arquivo simples. Parâmetros de configuração podem ser usados para fornecer transformação flexível de XML para arquivos simples. Em uma modalidade, o configurator 103 e as classes XmlException 708 são comuns a ambas a classe de consumidor 800 e classe de produtor 700 de uma estrutura 102. No entanto, o configurator 103 pode fornecer parâmetros de configuração adicionais para classe de consumidor 800. Além da configuração descrita acima em conexão com a classe de produtor 700, os seguintes parâmetros de configuração adicionais podem ser configurados para a classe de consumidor 800: • Configuração de Segmentos e subsegmentos • <translator-key>.segments=<ordered-list-of-segments>: lista todos os segmentos no XML na ordem em que eles aparecem no documento XML. Eles representam essencialmente os filhos imediatos distintos do elemento raiz do documento. • <translator-key>.segments.<segment-l>=<sub-segments- list>: em uma modalidade, esta entrada só é necessária quando filhos de segmentos configurados (subsegmentos) precisam ser processados sequencialmente. Eles representam filhos únicos de um segmento cujos subsegmentos precisam ser extraídos e processados sequencialmente. Em outras palavras, o aplicativo 101 pode extraí-los sequencialmente. • <translator-key>.segments.<segment-2>=<sub-segments-list>. • Configuração de referência cruzada: Em uma modalidade, a classe de consumidor 800 mantém dados na memória para um único segmento/subsegmento por vez. Em alguns casos, podem ser necessários dados de outros segmentos. Uma estrutura 102 fornece uma maneira para armazenar alguns dados contidos em um segmento/subsegmento para todo o ciclo de vida do documento XML que está sendo processado. Esses dados são denominados dados de referência cruzada. Os dados de referência cruzada podem ser configurados usando XPaths em segmentos e subsegmentos. A estes dados é dada uma identidade através de um identificador. O mesmo identificador pode ser usado para se referir aos dados extraídos durante todo o ciclo de vida do processamento XML. A seguir estão exemplos de configurações que podem ser usadas para configurar as referências cruzadas: • <translator-key>.xpaths.xref.names=<list-of-identifiers> • <translator-key>.xpaths.xref.<identifier-1 >=<xpath-for-identifier-1 > • <translator-key>.xapths.xref.<identifier-2>=<xpath-for-identifier-2>. • Configuração de personalização de erros de validação XSD: a configuração a seguir pode ser usada para extrair informações adicionais a serem anexadas a mensagens de erro de validação XSD para um determinado segmento: ■ <translator-key>.logs. segment. <segment-name>.names=<list-of-identifiers> ■ < translator-key > .logs. segment. < segment-name >. < identifier-l>.displayName=<name-to-be-appended-in-error-message> ■ < translator-key > .logs. segment. < segment-name >. < identifier-1> ref=<xpath | cross-ref-identifier> • < translator-key > .logs. segment. <segment-name >. <identifier- 1 >.type=<SEGMENT_XPATH | OPEN_SEGMENT_XPATH | X_RE F | COUNT | VALUE | SESSION_DATA>

[0136] Em uma modalidade, qualquer número de identificadores de registros pode ser associado com um segmento. Valores de identificadores configurados são avaliados com base no campo de tipo associado. Todos eles são avaliados com base no campo identificador. O valor avaliado e o nome especificado na entrada displayName são usados para gerar pares nome-valor a serem anexados à mensagem de erro de validação XSD. Por exemplo, para acrescentar a identificação de empregado com cada segmento de empregado inválido com o nome de exibição como EMPLOYEE, a configuração pode aparecer como a seguir: • <translator-key>. logs. segment. employee.names=employeeId • < translator- key > .logs .segment.employee.employeeld.displayName=EMP

LOYEE • <translator- key>. logs. segment. employee. employeeld. ref= employee/@id • <translator- key>. logs. segment. employee. employeeld. type=SEGMENT_X PATH.

[0137] Cada mensagem de erro de validaçao XSD de empregado de segmento pode ser acrescentada com • EMPLOYEE=<value of XPath queiy employee/@id>.

[0138] Estas informações adicionais auxiliam na ajuda à identificação do registro de empregado para cada validação XSD falhada.

[0139] Em uma modalidade, os seguintes tipos são suportados para configurações identificadoras de registro: SEGMENT_XPATH: campo de ref. correspondente a este tipo deve ser um XPath. XPath query é avaliada tratando o segmento como documento raiz. OPEN_SEGMENT_XPATH: campo de ref. correspondente a este tipo deve ser um XPath. XPath query é avaliada tratando o segmento aberto como documento raiz sem qualquer um de seus elementos filhos. X_REF: campo de ref. correspondente a este tipo deve ser um identificador de referência cruzada. VALUE: O valor do campo de ref. para este tipo é usado como um valor sem executar qualquer avaliação. COUNT: A contagem atual de registos de segmento especificados é avaliada como o valor do campo de ref. SESSION_DATA: dados da sessão de correspondência com chave especificada no campo de ref. são usados.

[0140] A seguir estão descrições de várias classes representadas na Fig. 8: [0141] A classe XmlConsumer 812 é usada para abstrair operações necessárias para processar um documento XML 107. O aplicativo 101 utiliza-a para processar segmentos/subsegmentos XML sequencialmente. O aplicativo 101 passa o nome de um segmento/subsegmento, e a estrutura 102 gera os objetos de dados de aplicativo correspondentes usando o segmento correspondente XML extraído pelo analisador StAX 104, camada de tradução 106 e objetos XMLBeans. Em modalidade, XmlConsumer class 812 inclui os seguintes métodos: • SegmentCursor openDataObject(String segmentName): o aplicativo 101 usa este método para obter um cursor para subsegmentos do segmento especificado. A interface SegmentCursor fornece métodos para recuperar objetos de dados de aplicativo correspondentes ao segmento e todos os seus subsegmentos. • Object getDataObject(String segmentName): o aplicativo 101 usa este método para recuperar um objeto de dados de aplicativo correspondente ao segmento especificado. Uma estrutura 102 extrai o segmento especificado XML usando o analisador StAX 104. O XML extraído e o nome do segmento são passados para a classe de tradutor. A classe de tradutor exemplifica o exemplo de XMLObject correspondente usando o nome de segmento e o segmento XML extraído. Uma estrutura 102 executa a validação XSD no XMLObject gerado pela classe de tradutor (se configurada). Identificadores de registros são extraídos do XMLObject como configurado e acrescentados aos erros de validação XSD. Erros de validação são entregues para os manipuladores de erro específicos do aplicativo (se fornecidos) para processamento posterior. Finalmente, a estrutura 102 passa o XMLObject e nome de segmento para a classe de tradutor. A classe de tradutor gera o objeto de dados de aplicativo correspondente que é retornado ao aplicativo 101. • void setErrorHandler( ErrorHandler handler): o aplicativo 101 pode, opcionalmente, definir um manipulador de erro que implementa a interface ErrorHandler. Erros de validação XSD são delegados ao manipulador de erro específicos do aplicativo para processamento adicional. • void doTransform(File transformedFile): o aplicativo 101 usa este método para transformar o arquivo XML em um arquivo simples. A transformação é impulsionada pela configuração especificada no arquivo de configuração. • void addSessionData(String key, Object value): o aplicativo 101 usa este método para adicionar dados específicos de aplicativo que são usados pela estrutura ou para enriquecer o arquivo transformado ou adicionar informações adicionais em erros de validação XSD.

[0142] XmlConsumerFactory class 811 é uma classe de fábrica que encapsula a criação de objetos implementando a interface XmlConsumer. Em uma modalidade, esta classe inclui dois métodos sobrecarregados para a criação de objetos - um com um objeto de arquivo e outro com um nome de arquivo do documento XML a ser processado.

[0143] ConsumerTranslator interface 809 abstrai operações fornecidas pela classe de tradutor de consumidor. A classe de implementação tem conhecimento suficiente para exemplificar um exemplo XMLObject apropriado do segmento de XML extraído. Mais tarde no processo, objetos de dados de aplicativo correspondentes são exemplificados de exemplos de XmlObject. Em uma modalidade, ConsumerTranslator interface 809 inclui os seguintes métodos: • XmlObject getRooNodeName(): A classe de tradutor retorna o nome do nó de documento raiz. Uma estrutura 102 utiliza-o para identificar o nó raiz no XML sendo processado. • XmlObject getXmlObject(String segmentName, String seg- mentXml, String namespaceStartWrapper, boolean isSubSegment): A classe de tradutor gera o exemplo correspondente XMLObject com base no nome do segmento passado e segmento XML. A classe de tradutor pode fazer uso de outros dois parâmetros, se eles forem necessários. XMLObject gerado é usado pela estrutura para executar validação XSD e extração de dados usando consultas XPath. • XmlObject getInnerXmlObject(String segmentName, XmlObject object): A classe de tradutor tem o conhecimento de um segmento e seu objeto XMLBeans (XmlObject). Ao gerar o XMLBeans de dados brutos de XML, um objeto XMLBeans pai é gerado no gráfico de objeto XMLBeans. O objeto XMLBeans retornado é usado pela estrutura 102 para executar validação XSD. • Object generateDataObject(XmlObject xmlObject): A classe de tradutor usa o objeto XMLBeans passado (XmlObject) para gerar um objeto de dados de aplicativo correspondente. O tipo concreto de exemplo de xmlObject passado é usado para determinar o tipo de objeto de dados de aplicativo a ser gerado.

[0144] XmlConsumerlmpl class 805 implementa a interface XmlConsumer 812. Um novo exemplo desta classe é retornado ao aplicativo 101 através de XmlConsumerFactoiy 811. O aplicativo 101 opera em um exemplo XmlConsumer 812 para processar segmentos XML sequencialmente, invocar métodos fornecidos em contratos de interface XmlConsumer 812 e SegmentCursor 806. Em uma modalidade, toda a coordenação entre analisador StAX 104, objetos SMLBeans gerados, camada de tradução 106 e manipulação de mensagem de validação é controlada por XmlConsumerlmpl class 805. Ela contém toda a funcionalidade necessária para processar XML sequencialmente, tal como: • Gerar objeto (s) de dados de aplicativo processando segmentos/subsegmentos XML e segmentos abertos. • Manter o controle de segmento(s) aberto(s). • Executar validações XSD em segmentos XML e delegar erros ao manipulador de erro. • Extração de dados configurados executando consultas XPath em exemplos XmlObject. • Extração de dados de referência cruzada. • Execução de transformações de XML para arquivo simples como configuradas.

[0145] Em uma encarnação, XmlConsumerlmpl class 805 implementa dois contratos diferentes: fornecer objetos de dados de aplicativo e transformar XML em um arquivo simples, conforme descrito abaixo.

[0146] Extração de objeto de dados. Objetos de dados de aplicativo são criados do segmento XML extraído do segmento solicitado. Em uma modalidade, as etapas a seguir são seguidas em ordem para realizar esta tarefa: 1. Extrair o segmento/subsegmento com base no nome de segmento/subsegmento passado pelo aplicativo 101. 2. A classe de tradutor gera um exemplo de XmlObject específico correspondente ao segmento XML extraído. 3. Extrair dados de referência cruzada de XPath configurados executando consultas XPath no XmlObject retornado. 4. Executar validação no XmlObject retornado e personalizar os erros de validação (se configurados), em seguida, entregar erros para um ErrorHandler 808 específico de aplicativo para processamento adicional. Dados adicionais (se configurados nas entradas de registro) são extraídos usando consultas XPath em XmlObject para adicionar valores de dados extraídos em mensagens de erro. 5. Ignorar o segmento atual se o segmento não passar na validação XSD e a opção pular inválida for verdadeira.Recuperar o próximo segmento e passá-lo através da etapa (2). 6. A classe de tradutor usa XmlObject para gerar objetos de dados de aplicativo correspondentes. 7. O objeto de dados específico de aplicativo gerado é retornado ao aplicativo 101.

[0147] Transformação XML - > arquivo simples. Em uma modalidade, as seguintes etapas são executadas para transformar XML em um arquivo simples: 1. Extrair o segmento (se configurado) necessário para gerar o cabeçalho do arquivo simples. 2. A classe de tradutor gera um exemplo de XmlObject específico correspondente ao segmento XML extraído. 3. Extrair os dados de referência cruzada XPath executando consultas XPath no XmlObject retornado. 4. Executar validação no XmlObject retornado e personalizar os erros de validação (se configurados), em seguida, entregar erros ao ErrorHandler 808 para processamento adicional. Dados adicionais (se configurados em entradas de registro) são extraídos usando consultas XPath em XmlObject para adicionar valores de dados extraídos em mensagens de erro de validação. 5. Extrair dados do XmlObject retornado e executar consultas XPath para recuperar os dados e popula-los no arquivo simples. 6. Repetir as etapas (1) a (5) para todos os segmentos de corpo e subsegmentos. 7. Acrescentar no arquivo simples (se configurado).

[0148] Além de implementar os métodos de interface, XmlConsumerlmpl class 805 pode também incluir métodos internos, tal como: • protected void setup (File xmlOutFile, ConsumerTranslator trans, Segment[ ] segments, XPathCrossReference[ ] xPathCrossRef, boolean includelnvalid, boolean loglnvalid): Class configurator 709 cria um novo exemplo desta classe quando o aplicativo 101 solicita um exemplo de XmlConsumer via XmlConsumerFactory. Um exemplo da classe de tradutor é, então, criado e invocado neste método para passar informações de configuração (por exemplo, se validação XSD precisa ser executada, seja para registrar erros de validação XSD e uma lista de segmentos e seus subsegmentos). • private XmlObject getSegmentXmlObject(String segment- Name): este método é responsável por extrair o segmento XML correspondente ao nome de segmento passado. O analisador StAX 104 é usado para extrair o segmento XML. A classe de tradutor cria o objeto correspondente XMLBeans do XML extraído. • private XmlObject openSegment(String segmentName): este método é responsável por extrair o segmento XML (sem qualquer um dos seus elementos filhos) correspondente ao nome de segmento passado. A análise é interrompida assim que um filho do segmento nomeado é detectado. Um XML bem formado é gerado acrescentando a etiqueta de fechamento. XML extraído (com etiqueta de fechamento acrescentada) é passado para a classe de tradutor. A classe de tradutor cria o objeto correspondente XMLBeans do XML extraído.

• private boolean analyze(String segmentName, XmlObject XmlObject): uma estrutura 102 usa este método para executar validação XSD e registrar quaisquer erros XSD, se configurada para fazê-lo. A classe de tradutor fornece o objeto XMLBeans interno ou o mesmo objeto dependendo da definição de XSD. Validação de XSD é executada no objeto XMLBeans retornado. Mensagens de erro (se houver) são personalizadas com base na configuração fornecida. Finalmente, a mensagem de erro é entregue ao ErrorHandler 808 para processamento adicional.

[0149] SegmentCursorlmpl class 807 fornece a implementação de uma interface SegmentCursor 806 para iterar sobre os subsegmen-tos de um segmento aberto.

[0150] XPathCrossReference class 810 encapsula os dados de configuração relacionados a referências cruzadas XPath e fornece métode ajuste/obtenção para ajustar e obter este dados.

[0151] Field class 801 encapsula o nome configurado e o tipo de um identificador; exemplos incluem SEGMENT_XPATH, OPEN_SEGMENT_XPATH, X_REF, VALUE, COUNT, SESSION_DATA e USER_DEFINED. Field class 801 fornece métodos de ajuste/obtenção para nomes e tipos.

[0152] LogField class 802 estende Field class 801 e adiciona variáveis adicionais para reter um nome de exibição e métodos de obter/ajustar relacionados.

[0153] Separador class 813 encapsula os dados de configuração relacionados a separadores de registros e de campos necessários ao fazer transformação XML para arquivo simples.

[0154] TransformConfig class 804 encapsula todos os dados de configuração (tal como cabeçalho, corpo, rodapé etc.) necessários para transformar XML em um arquivo simples.

[0155] Segmento class 803 encapsula informações de configuração sobre um segmento, tal como seu nome, segmento pai (se houver) e subsegmentos (se houver).

Configuração de Transformação de XML para Arquivo Simples [0156] Como discutido acima, em uma modalidade o arquivo simples gerado pela estrutura 102 tem três seções: cabeçalho, corpo e rodapé. Em uma modalidade, a estrutura 102 fornece múltiplas opções de configuração para cada uma destas seções, como a seguir: Cabeçalho [0157] O cabeçalho contém metadados, tal como informações de remetente, ID de transação, número de registros e assim por diante. Dados podem ser extraídos de qualquer segmento XML a ser gravado no cabeçalho. Um exemplo de sintaxe para a configuração é a seguinte: [0158] <translator-key>.transform.header.segment=<segment-name>.

[0159] <translator-key>.transform.header.fields=<list-of-(ref:type)- pair>.

[0160] segment-name é o nome do segmento XML de onde os dados precisam ser extraídos executando consultas XPath como especificado na configuração de campos. Em uma modalidade, a configuração de campos é idêntica à configuração de personalização de erros de validação XSD. No entanto, ref. e tipo são separados por dois pontos e podem ser configurados por vírgula separando cada par. A parte de ref. é avaliada com base no tipo configurado. XPath configurado nesta seção geralmente avalia um texto simples ou um valor de atributo único. Os valores avaliados são populados no cabeçalho do arquivo simples na mesma ordem conforme configurado aqui. Valores populados em arquivo transformado são separados por um delimitador. O valor do delimitador pode ser configurado conforme discutido abaixo.

Corpo [0161] Qualquer número de segmentos pode ser configurado usando um formato semelhante aquele mostrado acima para a parte do cabeçalho. Em geral, todos os subsegmentos de um segmento configurado são recuperados recursivamente e um registro é criado e anexado no arquivo transformado toda vez que ele encontra um subsegmento especificado. Como observado anteriormente, a lista de segmentos e seus subsegmentos é configurada na ordem em que eles aparecem no documento XML. <translator-key>.transform.body.segments=<segments-list> <translator-key>.transform.body.<segment-l>.fields=<list-of- {ref: type) -pair > <translator-key>.transform.body.<segment-2>.fields=<list-of- (ref: type) -pair >

Rodapé [0162] A configuração de rodapé fornece suporte para criar um registro de resumo e acrescentá-lo no arquivo transformado no final. Ela segue o formato semelhante como descrito acima para o cabeçalho: <translator-key>.transform.footer.fields=<list-of-(ref:type)-pair>.

Delimitadores Campo e Registro [0163] Em uma modalidade, quaisquer delimitadores podem ser especificados. A configuração a seguir pode ser usada para especificar delimitadores nos arquivos transformados: <translator-key>.transform.fieldSeparator=<expression-to-be- evaluated> <translator- key>.transform.fieldSeparator.type=VALUE | SYSTEM_PROPERTY | SESSION_DATA <translator-key>.transform.lineSeparator=<expression-to-be- evaluated> <translator- key>.transform.lineSeparator.type=VALUE | SYSTEM_PROPERTY | SESSION_DATA

Exemplo [0164] A seguir é um exemplo de geração (produção) e processamento (consumo) de um documento XML usando as técnicas da presente invenção 107. Para fins de ilustração, o exemplo usa o seguinte XSD: <xml version=“l,0” encoding=“UTF-8” standalone=“yes”> <xs:schema xmlns : mp=“ http: / / www. walmart .com/2009 / XM LS chema / fulfillm ent/mp” xmlns :xs=“http: //www.w3.org/2001 /XMLSchema” target- Namespace=“http: / /www.walmart.com/2009/XMLSchema/fulfill ment/mp” elementFormDefault=aunqualifled”> <xs:complexType name=“availabilityType”> <xs:attribute name=“code” use=“required” type=“xs:string”/> <xs:attribute name=“quantity” use=“required” type=“xs:int”/> < / xs: complexType > <xs: complexType name=“itemType”> <xs:sequence> <xs:element name=“availability” type=“mp:availabilityType”/ > < /xs:sequence> <xs:attribute name=“itemld” use=“required” type=“xs:long”/> < / xs: complexType > <xs:complexType name=“promotionType”> <xs:attribute name=“code” use=“required” type=“xs:string”/> <xs:attribute name=“description” use=“optionar’ type=“xs:string”/> < / xs: complexType > <xs:complexType name=“promotionsType”> <xs:sequence> <xs:element name=“promotion” type=“mp:promotionType” maxOccurs=“unbounded’7 > < /xs:sequence> < / xs: complexType > <xs:complexType name=ainventoryType”> <xs:sequence> <xs:element name=“item” type=“mp:itemType” max-Occurs=“unbounded”/ > < /xs:sequence> < / xs: complexType > <xs:element name=“wmi”> <xs: complexType > <xs: sequence > <xs:element name=“transactionInfo”> <xs: complexType > <xs: sequence > <xs:element name=“from”> <xs:complexType> <xs:attribute name=“id” use=“required” type=“xs: long” / > <xs:attribute name=“name” use=“required” type=“xs:string”/> </xs:complexType> </xs:element> </xs: sequence > <xs:attribute name=“transactionId” use=“required” type=“xs:long”/ > <xs:attribute name=“transactionDate” use=“required” type=“xs:date”/ > < / xs: complexType > </xs:element> <xs:element name=“inventory” type=“mp:inventoryType” minOccurs=“0”/ > <xs:element name=“promotions” type=“mp:promotionsType” minOccurs=‘O”/ > </xs:sequence> < /xs:complexType> </xs:element> </xs:schema>

[0165] A seguir é um documento XML de amostra 107 conforme o XSD acima: <xml version=“1.0” encoding=“UTF-8”> <mp:wmi xmlns:mp=“http: //www.walmart.com/2008/XMLSchema/fulfillment/m p”> <transactionInfo transactionId=“7348891” transac-tionDate=“2009-01 -22”> <from id=“255045” name=“Home Partner”/> </transactionInfo> <inventory> <item itemld=“3918290”> <availability code=“AA” quantity=“200”/ > < / item> <item itemld=“6561233”> <availability code=“AC” quantity=“50”/> </item> </inventory> <promotions> <promotion code=“HOLIDAY” description=“Holiday Spe- cial’V> <promotion code=“SIZZLING” description=“Summer Spe- cia Γ/> </promotions> </mp:wmi>

[0166] O exemplo a seguir demonstra operações de produtor, consumidor e transformação de arquivo para o XSD acima e o XML de amostra.

[0167] A primeira é gerar XMLBeans classes. O comando a seguir é usado para gerar XMLBeans classes: scomp -d classes -src src sample.xsd.

[0168] Este comando gera classes de interface Java estendendo o XMLBeans. A seguir está uma lista de classes Java de interface de amostra para este processo: AvailabilityType. j ava ItemType. j ava PromotionsType.java Pr omotionType. j ava Invento ryType. java WmiD ocume nt. j ava [0169] A camada de tradução 106 precisa de objetos de dados de aplicativo para operar. Eles são usados para gerar XML pelo tradutor de produtor. O tradutor de consumidor cria seus exemplos do XML extraído. Objetos de dados não estão cientes de quaisquer eventos XML ou objetos XMLBeans. No entanto, eles precisam fornecer maneiras de extrair dados deles quando sendo usados pelo tradutor de produtor e fornecer maneiras para popular dados quando sendo usado por tradutores de consumidor. Para fins ilustrativos, pressupomos que o aplicativo 101 tem as seguintes três classes para encapsular os dados representados na amostra XML: • HeaderDto, que encapsula os dados de nível de cabeçalho, tal como ID de transações, data de transação e informações sobre o remetente do documento XML; • InventoryDto, que encapsula informações de inventário de um item; e • PromotionDto, que encapsula os dados de promoção.

[0170] Exemplos destas classes são mostrados abaixo.

Class HeaderDto public class HeaderDtoj private long _transactionId; private Calendar _transactionDate; private long _senderld; private String _senderName; public HeaderDto(){} public HeaderDto (long transactionld, Calendar transac- tionDate, long senderld, String senderName){ _transactionId = _transactionId; _transactionDate = _transactionDate; _senderld = senderld; _senderName = senderName; } public long getTransactionId() {return _transactionId;} public void setTransactionId(long id) {_transactionId = id;} public Calendar getTransactionDate() {return _transactionDate;} public void setTransactionDate(Calendar date){ _transactionDate = date; } public long getSenderldf) {return _senderld;} public void setSenderId(long id) {_senderld = id;} public String getSenderName(){return _senderName;} public void setSenderName(String name) {_senderName = name;} public String toString(){ StringBuffer sb = new StringBuffer(); sb.append(this.getClass().getName() + “ : [_transactionI d=“+_trans actio nld); sb.append(“, _transactionDate=“+_transactionDate); sb.append(“, _senderld=“+_senderld); sb.append(“, _senderName=“+_senderName); sb.append(“]”); return sb.toString(); } } Class InventoryDto public class InventoryDto{ private long _itemld; private String __code; private int _quantity; public InventoryDto (){ } public InventoryDto (long itemld, String code, int quantity){ _itemld = itemld; _code = code; _quantity = quantity; } public long getltemld() {return _itemld;} public void setItemId(long id) {_itemld = id;} public int getQuantity() {return _quantity;} public void setQuantity(long quantity) {_quantity = quantity;} public String getCode() {return _code;} public void setCode(String code) (_code = code;} public String toString(){ StringBuffer sb = new StringBuffer(); sb.append(this.getClass().getName() + “ : [_itemld=“+_itemld); sb.append(“, _code=“+_code); sb.append(“, _quantity=“+_quantity); sb.append(“]”); return sb.toString(); } } Class PromotionDto public class PromotionDto{ private String _code; private String _detail; public PromotionDto (){ } public PromotionDto (String code, String detail){ _code = code; _detail = detail; } public String getDetailQ { return _detail; } public void setDetail(String detail) {_detail = detail;} public String getCode() {return _code;} public void setCode(String code) {_code = code;} public String toString(){ StringBuffer sb = new StringBuffer(); sb.append(this.getClass().getName() + “ : [_code=“+_code); sb. append(“, _detail=“+_detail); sb.append(“]”); return sb.toString(); } } [0171] Conforme discutido anteriormente, as classes de tradutor de produtor implementam a interface ProducerTranslator e as classes de tradutor de consumidor implementam a interface ConsumerTransla-tor.

Tradutor de Produtor [0172] Em uma modalidade, a estrutura 102 pode generar documento XML 107 em qualquer uma de três maneiras diferentes: • Gerar o documento inteiro XML 107 ao mesmo tempo. Esta abordagem é viável quando não há muitos elementos de inventário e promoção. O aplicativo 101 fornece objetos de dados de aplicativo que tem todos os dados necessários para produzir o documento inteiro XML 107. No entanto, em uma modalidade, o contrato de interface XmlCon-sumer permite a passagem de apenas um único objeto. Neste caso, os dados são encapsulados em vários objetos de dados - exemplos Hea- derDto, InventoryDto[] e PromotionDto[]. Isso pode ser feito de duas maneiras: ou emrolar todos os objetos em outro objeto, ou colocar todos eles em um HashMap. Para fins ilustrativos, a abordagem HashMap será usada neste exemplo. • Gerar documento XML 107 incrementalmente adicionando segmentos transactionlnfo, inventário e promoções na ordem determinada. O aplicativo 101 passa exemplos de Header, Inventory[] e Promo-tion[] sequencialmente para a estrutura 102 para que cada segmento possa ser adicionado ao XML. • Gerar XML segment transactionlnfo e, em seguida, abrir seg-ment inventory e adicionar seu item de subsegmentos sequencialmente. Da mesma forma, gerar open segment promotions e adicionar promoção de subsegmentos sequencialmente. O aplicativo 101 passa exemplos de HeaderDto de modo que o segmento transactionlnfo XML pode ser gerado. Open segment inventory segue o segmento transactionlnfo e exemplos de objetos InventoryDto são passados para a estrutura 102 sequencialmente. O mesmo processo (como no caso de inventário) é repetido para promoções.

[0173] A classe de tradutor de produtor é capaz de lidar com cada um destes casos; por conseguinte, ela é capaz de exemplificar objetos XML correspondentes em todos os três casos.

[0174] O arquivo de propriedades é configurado para usar esta classe de tradutor, por exemplo, adicionando as seguintes entradas: classes. keys=invTestProducer invTestProducer.class=InventoryProducerTranslator invTestProducer. includelnvalid=false invTestProducer. log!nvalid=true [0175] Para gerar o documento inteiro XML 107 ao mesmo tempo, o aplicativo 101 fornece os dados (sob a forma de DTOs) necessários para gerar o documento XML 107. A classe de tradutor é implementada de forma que ela possa compreender o que o aplicativo 101 está tentando realizar. Por exemplo, o aplicativo 101 pode passar um HashMap contendo exemplos de objetos de dados de aplicativo - HeaderDto, matriz InventoryDto[ ] e matriz Promotion[ ] com cabeçalho de chaves, inventário e promoções respectivamente. Uma vez que este parâmetro é recebido, a estrutura 102 pode gerar o documento inteiro XML 107. Um exemplo de documento XML 107 gerado por esta abordagem é o seguinte: <xml version=“1.0” encoding=“UTF-8”> <mp:wmi xmlns: mp=“http: / / www.walmart.com /2009/ XMLSchema / fulfillment / m p”> ctransactionlnfo transactionId-“789569” transac-tionDate=“2009-03-26”> <from id=“7348891” name=“Home Partner”></from> </transactionInfo> <inventory> citem itemld=“3918290”> cavailability quantity=“200” code=“AA”></availability> </item> citem itemld=“6561233”> cavailability quantity=“50” code=“AC”></availability> c/item> </inventory> <promotions> <promotion description=“Holiday Special” code=“HOLIDAY”>< /promotion> <promotion description=“Summer Special” code=“SIZZLING”>< / promotion> </promotions> </mp:wmi>

[00176] Para gerar o documento XML 107 incrementalmente, segmentos transactionlnfo, inventory e promotions são adicionados em sequência. Por exemplo, a estrutura 102 gera o segmento XML transactionlnfo de HeaderDto, inventory segment de matriz InventoryDtof ] e promoções de matriz PromotionDto[ ].

[00177] Para gerar o documento XML 107 adicionando segmentos e subsegmentos sequencialmente, um segmento transactionlnfo é adicionado em primeiro lugar, seguido de um item de subsegmentos de inventário e promoção de subsegmentos de promoções sequencialmente. A estrutura 102 primeiro gera o segmento transactionlnfo XML do exemplo HeaderDto. Em seguida, ela adiciona um open segment para inventário e adiciona todos os seus subsegmentos sequencialmente. Depois de fechar o segmento de inventário, o open segment promotions é adicionado. Todos seus subsegmentos mais tarde são adicionados em sequência. Uma chamada para closeAll() fecha todos os segmentos abertos na ordem em que eles foram abertos.

Consumer Translator [00178] Em uma modalidade, a estrutura 102 pode processar documento XML 107 em qualquer uma de três maneiras diferentes: • Extrair sequencialmente segmentos (tal como transactionlnfo, inventory e promotions). O aplicativo 101 pode recuperá-los em sequência. Todos os subsegmentos destes segmentos serão recuperados juntamente com o respectivo segmento. • Extrair segmento transactionlnfo e, em seguida, open segment inventory seguido de extração sequencial de seus subsegmentos (item). Finalmente, open segment promotions seguido de extração sequencial de seus subsegmentos (promoção). • Transformar um documento XML 107 em um arquivo simples conforme especificado no arquivo de configuração.

[00179] Consumer translator class é usado para lidar com qualquer um destes casos.

[00180] O arquivo de propriedades é configurado para usar esta classe de tradutor, por exemplo, adicionando as seguintes entradas: invTestConsumer.class=InventoryConsumerTranslator invTestConsumer.includeInvalid=false invTestConsumer. logInvalid=true invTestConsumer.segments=transactionInfo, inventory, promotions invTestConsumer. segments. invento ry=item invTestConsumer. segments. promotions=promotion [00181] Essas entradas instruem a estrutura 102 da seguinte forma: • Usar a classe InventoryConsumerTranslator para tradução. • Não incluir os segmentos/subsegmentos que falham na vali- dação XSD. • Fazer registro dos erros de validação XSD. • Existem três filhos do nó raiz - transactionlnfo, inventário e promoções; estes são denominados como segmentos. • Item é o único subsegmento (nó filho) do segmento de inventário. • Promoção é o único subsegmento (nó filho) do segmento de promoções.

[00182] Como discutido acima, a estrutura 102 pode processar documento XML 107 extraindo segmentos (transactionlnfo, inventário e promoções) sequencialmente se desejado. Um exemplo de saída gerada por esse processamento é o seguinte: HeaderDto : [_transactionId=789569, _transactionDate=2009-03-26, _senderld=7348891, _senderName=Home Partner] InventoryDto : [_itemld=3918290, _code=AA, _quantity=200] InventoryDto : [_itemld=6561233, _code=AC, _quantity=50] PromotionDto : [_code=HOLIDAY, _detail=Holiday Special] PromotionDto : [_code=SIZZLING, _detail=Summer Special] [00183] Promoção e subsegmentos de item podem ser processados sequencialmente. O processamento de subsegmentos sequencialmente pode ser útil quando um grande número de subsegmentos é esperado e extrair todos eles juntos pode fazer o aplicativo 101 ficar sem memória.

[00184] Em primeiro lugar, a estrutura 102 processa o segmento de tamanho fixo transactionlnfo. Depois de processar o segmento transactionlnfo, o aplicativo 101 pede a estrutura 102 para abrir o inventory segment e processa subsegmentos de item sequencialmente. Finalmente, o aplicativo 101 pede a estrutura 102 para abrir o segment promotions e processa a promoção de subsegmentos sequencialmente.

[00185] Quando traduzindo o documentos XML 107 para um arquivo simples, os dados transformados têm duas fontes diferentes: XML e especificada pelo aplicativo. Dados XML a serem extraídos são expressos usando XPaths; dados especificado pelo aplicativo são expressos como dados de sessão. Em uma modalidade, os dados são configurados apropriadamente para cada seção do arquivo simples a ser gravado: cabeçalho, corpo e rodapé. Por exemplo, suponha que o cabeçalho incluirá os seguintes campos, todos provenientes do segmento transactionlnfo: • transactionld • sender Id • sender Name [00186] Suponha que o corpo de arquivo simples incluirá campos dos segmentos de inventário e promoções. Campos correspondentes a um subsegmento constituirá um registo de corpo no arquivo transformado. Sender Id e transaction Id do segmento transactionlnfo serão incluídos através de referências cruzadas. Além disso, cada registro de inventário deve começar com a palavra INVENTORY e o registro de promoção com a palavra PROMOTION. Além disso, suponha que a contagem de registro cumulativo e o campo especificado de aplicativo - data de processamento também serão adicionados. Os campos a seguir constituem um inventário/promoção e registro de rodapé no arquivo simples: • Inventory Segment • A palavra INVENTORY como ela é; • sender Id de transactionlnfo segment; • item id; • código de disponibilidade; • quantidade de disponibilidade; • dados de aplicativo - data de processamento; • transaction id de transactionlnfo segment; • contagem de registro de item cumulative dentro do inven-tory segment. • Promotions Segment • palavra PROMOTION como ela é; • sender Id de transactionlnfo segment; • código de promoção; • transaction id de transactionlnfo segment; • contagem de registro de promoção cumulative dentro do segment de promoções. • Rodapé • transaction id de transactionlnfo segment; • Número de registros de item; • Número de registros de promoção; • Número total de registros de promoção e itens.

[00187] A seguir é um exemplo de configuração para incluir os campos acima no arquivo transformado: invTestConsu- mer.xpaths.xref.names=transactionId,senderId,senderName invTestConsu- mer.xpaths.xref.transactionId=transactionInfo/@transactionId invTestConsumer.xpaths.xref.senderId=transactionInfo/from/@id invTestConsu- mer .xpaths. xref. senderN ame=transactionlnfo / from / @name invTes tConsumer. transform. header. segment=transactionInfo invTestConsu- mer. transform. header. flelds=transactionId:X_REF,transactionInfo / from/@id:SEGMENT_XPATH,senderName:X_REF invTestConsumer. transform.body.segments=inventory,promotions invTestConsum- er. transform. body.fields.inventory=INVENTORY:VALUE,senderId: X_REF,inventory/item/@itemId:SEGMENT_XPATH,inventory/ite m/availability/@code:SEGMENT_XPATH,inventory/item/availabil ity/@quantity:SEGMENT_XPATH,processingDate:SESSION_DATA, transactionId:X_REF,item:COUNT

invTestConsumer. transform.body.fields.promotions=PROMOTION:VALUE,senderI d:X_REF,promotions/promotion/@code:SEGMENT_XPATH, transa ctionId:X_REF,promotion:COUNT

invTestConsumer. transform.footer.fields=transactionId:X_REF,item:COUNT,prom otion:COUNT,item+promotion:COUNT

[00188] Campos que estão sendo referenciados cruzados de um segmento para outro são incluídos na lista de config. De referência cruzada.

[00189] Um exemplo do arquivo simples resultante é o seguinte: 789569 | 7348891 | Home Partner INVENTORY |7348891 | 3918290 |AA| 200] Thu Mar 26 11:55:31 PDT 2009|789569|1 INVENTORY | 7348891 | 6561233 | AC | 50 | Thu Mar 26 11:55:31 PDT 2009|789569|2 PROMOTION | 7348891 | HOLIDAY | 789569 | 1 PROMOTION | 7348891 | SIZZLING | 789569 | 2 789569|2]2|4 [00190] Neste exemplo, a estrutura 102 usa a saída da função toStringO de todos os dados adicionados ao aplicativo. Separador de registro padrão (nova linha) e separador de campo padrão (|) são usados, pois eles não foram especificados.

[00191] Em uma modalidde, a mensagem de erro de validação XSD pode ser personalizada acrescentando informações adicionais nela. Por exemplo, suponha que queremos adicionar transactionId(via referência cruzada) e itemld sempre que um subsegmento de item falha na validação XSD. O nome de exibição para transactionld deve ser TRANSACTION ID e Item # para itemld. Entradas de configuração para esta personalização podem ser as seguintes: invTestConsumer.logs.segment.item.names=transactionId,item_Id invTestConsu- mer.logs.segment. item. transactionld. displayName=TRANSACTION invTestConsu- mer. logs. segment. item. transactionId.ref=transactionId invTestConsumer.logs. segment. item. transactionId.type=X_REF invTestConsumer.logs.segment.item.item_Id.displayName=Item invTestConsu- mer. logs. segment. item. item_Id. ref=inventory / item /@itemld invTestConsumer. logs. segment. item.item_Id.type=SEGMENT_XPATH

[00192] Uma mensagem de erro, em seguida, é a seguinte: Invalid decimal value: unexpected char '88' [TRANSACTION ID = 789569, Item # = 3918290] [00193] Informações dentro de colchetes quadrados foram adicionadas pela estrutura 102 (conforme configurada) para inclusão quando um segmento item inválido ê encontrado.

Conclusão [00194] Com base na descrição acima pode ser visto que, em várias modalidades, o sistema da presente invenção fornece várias vantagens sobre os esquemas do estado da técnica. O sistema da presente invenção combina o fluxo contínuo e a flexibilidade de um analisador StAX com o poder e a facilidade de uso de XMLBeans, para que documentos XML de tamanho arbitrário possam ser processados e/ou gerados em série. Além disso, o código de aplicativo pode ser isolado dos detalhes de análise e processamento de documentos XML, tornando o código de aplicativo mais fácil de manter e facilitando a troca com outra tecnologia XML sem impactar o aplicativo.

[00195] Em várias modalidades, a presente invenção pode ser implementada como um sistema ou um método para executar as técnicas acima descritas, ou isoladamente ou em qualquer combinação.

Em outra modalidade, a presente invenção pode ser implementada como um produto de programa de computador compreendendo um meio de armazenamento legível por computador não transitório e código de programa de computador, codificado no meio, para fazer com que um processador em um dispositivo de computação ou outro dispositivo eletrônico execute as técnicas acima descritas.

[00196] Referência no relatório a “uma modalidade” ou “a modalidade” significa que um determinado recurso, estrutura ou característica descrita em conexão com as modalidades está incluída em pelo menos uma modalidade da invenção. As aparições da frase “em uma modalidade” em vários lugares no relatório não estão necessariamente todas se referindo à mesma modalidade.

[00197] Algumas porções do texto acima são apresentadas em termos de algoritmos e representações simbólicas de operações em bits de dados dentro de uma memória de computador. Estas descrições algorítmicas e representações são os meios utilizados por aqueles versados na técnica de processamento de dados para mais efetivamente transmitir a substância de seu trabalho a outros versados na técnica. Um algoritmo é aqui e geralmente concebido para ser uma sequência autoconsistente de etapas (instruções) conduzindo a um resultado desejado. As etapas são aquelas que exigem manipulações físicas de grandezas físicas. Geralmente, embora não necessariamente, estas quantidades assumem a forma de sinais elétricos, magnéticos ou ópticos capazes de serem armazenados, transferidos, combinados, comparados, transformados e de outra forma manipulados. É conveniente, por vezes, principalmente por razões de uso comum, se referir a estes sinais como bits, valores, elementos, símbolos, caracteres, termos, números ou similares. Além disso, é também conveniente, por vezes, se referir a certas disposições de etapas que exigem manipulações físicas de grandezas físicas como módulos ou dispositivos de código, sem perda de generalidade.

[00198] Deve-se ter em mente, no entanto, que todos estes e termos semelhantes estão associados com as grandezas físicas adequadas e são meramente rótulos convenientes aplicados a estas quantidades. A menos que especificamente indicado de outra forma, como é aparente da discussão a seguir, é apreciado que em toda a descrição, discussões utilizando termos como “processamento” ou “computação” ou “cálculo” ou “determinação” ou “exibição” ou similares, se referem à ação e processos de um sistema de computador ou dispositivo de computação eletrônica semelhante, que manipula e transforma dados representados como grandezas físicas (eletrônicas) dentro das memórias de sistema de computador ou registos ou outros dispositivos de armazenamento, transmissão ou exibição de informações.

[00199] Certos aspectos da presente invenção incluem etapas de processo e instruções aqui descritas na forma de um algoritmo. Note-se que as etapas de processo e as instruções da presente invenção podem ser incorporadas em software, firmware ou hardware e quando integradas em software podem ser baixadas para residir em e ser operadas de diferentes plataformas usadas por uma variedade de sistemas operacionais.

[00200] A presente invenção refere-se também a um aparelho para executar as operações aqui. Este aparelho pode ser construído especialmente para as finalidades necessárias, ou ele pode compreender um ou mais computadores de uso geral seletivamente ativados ou reconfigurados por um programa de computador armazenado no computador. Um programa de computador pode ser armazenado em um meio de armazenamento legível por computador, tal como, mas não limitado a, qualquer tipo de disco, incluindo disquetes, discos óticos, CD-ROMs, discos magnético-ópticos, memórias de leitura apenas (ROMs), memórias de acesso aleatório (RAM), EPROMs, EEPROMs, cartões magnéticos ou ópticos, application specific integrated circuits (ASICs), ou qualquer tipo de mídia adequada para armazenar instruções eletrônicas e cada qual acoplado a um barramento de sistema de computador. Além disso, os computadores e/ou outros dispositivos eletrônicos citados no relatório podem incluir um único processador ou podem ser de arquiteturas empregando vários projetos de processador para maior capacidade de computação. Em uma modalidade, alguns ou todos os componentes funcionais descritos acima são implementados como hardware de computador, incluindo processadores executando as etapas descritas acima sob o controle de software.

[00201] Os algoritmos e exibições apresentados neste documento não são inerentemente relacionados a qualquer computador específico ou outro aparelho. Vários sistemas de uso geral também podem ser usados com programas de acordo com os ensinamentos deste documento, ou eles podem revelar-se convenientes para construir aparelho mais especializado para executar as etapas de método necessárias. A estrutura necessária para uma variedade destes sistemas aparecerá da descrição abaixo. Além disso, a presente invenção não é descrita com referência a qualquer linguagem de programação específica. Será apreciado que uma variedade de linguagens de programação pode ser usada para implementar os ensinamentos da presente invenção conforme descritos neste documento e quaisquer referências abaixo a linguagens específicas são fornecidas para divulgação de habilitação e melhor modo da presente invenção.

[00202] Por conseguinte, em várias modalidades, a presente invenção pode ser implementada como software, hardware ou outros elementos para controlar um sistema de computador, dispositivo de computação ou outro dispositivo eletrônico ou arquitetura cliente/ servidor, ou qualquer combinação ou pluralidade dos mesmos. Hardware para implementação do sistema da presente invenção pode incluir, por exemplo, um processador, um dispositivo de entrada (tal como um teclado, mouse, touchpad, trackpad, joystick, trackball, microfone ou qualquer combinação dos mesmos), um dispositivo de saída (tal como uma tela, alto-falante, e/ou similares), memória, armazenamento de longo prazo (tal como armazenamento magnético, armazenamento óptico e/ou similares) e/ou conectividade de rede de acordo com técnicas que são bem conhecidas na arte. Tal dispositivo eletrônico pode ser portátil ou não portátil. São exemplos de dispositivos eletrônicos que podem ser usados para implementar a invenção (ou componentes da invenção): um telefone celular, assistente digital pessoal, smartphone, quiosque, computador desktop, notebook, dispositivos eletrônicos de consumidor, televisão, decodificadores ou similares. Um dispositivo eletrônico para implementar a presente invenção pode usar um sistema operacional tal como, por exemplo, Microsoft Windows 7 disponível de Microsoft Corporation de Redmond, Washington, ou qualquer outro sistema operacional que está adaptado para uso no dispositivo.

[00203] Por último, deve notar-se que a linguagem usada no relatório foi principalmente selecionada para legibilidade e fins de instrução e pode não ter sido selecionada para delinear ou circunscrever a matéria inventiva. Por conseguinte, a divulgação da presente invenção pretende ser ilustrativa, mas não limitadora do escopo da invenção, que é estabelecido nas reivindicações a seguir.

[00204] Embora a invenção tenha sido particularmente mostrada e descrita com referência a uma modalidade preferida e várias modalidades alternativas, será compreendido por aqueles versados na técnica relevante que várias alterações na forma e nos detalhes podem ser feitas sem se afastar do espírito e escopo da invenção.

Claims

1 - Método Implementado em Computador Para Processar Documento XML, caracterizado por compreender: em um processador, receber uma mensagem de um aplicativo solicitando dados do documento XML; em um processador, responsivo a receber a mensagem: recuperar, do documento XML, pelo menos um segmento que representa os dados solicitados; converter pelo menos um segmento recuperado em uma representação XML baseada em objeto; e transformar a representação XML baseada em objeto em pelo menos um objeto de dados de aplicativo; e em um processador, transmitindo pelo menos um objeto de dados de aplicativo para o aplicativo.

2 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por: a transformação da representação XML baseada em objeto em pelo menos um objeto de dados de aplicativo compreender traduzir pelo menos um objeto de dados XML em pelo menos um objeto de domínio de aplicativo; e a transmissão de pelo menos um objeto de dados de aplicativo extraído para o aplicativo compreender transmitir o objeto de domínio de aplicativo traduzido para o aplicativo.

3 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a representação baseada em objeto compreender um objeto em uma estrutura de ligaçao XML.

4 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a representação baseada em objeto compreender um objeto XMLBeans.

5 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a recuperação de pelo menos um segmento que representa os dados solicitados compreender: enviar uma solicitação para um analisador recuperar pelo menos um segmento; e receber o segmento do analisador.

6 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 5, caracterizado por o analisador compreender um analisador StAX.

7 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por ainda compreender: em um processador, validar a representação baseada em objeto.

8 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 7, caracterizado por a validação da representação baseada em objeto compreender: em um processador, efetuar validação na representação baseada em objeto contra uma definição de esquema XML.

9 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a recuperação do documento XML de pelo menos um segmento que representa os dados solicitados compreender: em um processador, recuperar pelo menos um segmento; e em um processador, recursivamente recuperar pelo menos um subsegmento do segmento recuperado.

10 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a recuperação do documento XML de pelo menos um segmento que representa os dados solicitados compreender: em um processador, solicitar uma localização de pelo menos um segmento do documento XML de uma configuração; em um processador receber a localização solicitada; e em um processador, recuperar dados da localização solicitada.

11 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 10, caracterizado por a recuperação de dados da localização solicitada compreender: em um processador, chamar um analisador para analisar o documento XML para recuperar os dados.

12 - Método Implementado em Computador Para Processar Documento XML, de acordo com a Reivindicação 1, caracterizado por a recuperação do documento XML de pelo menos um segmento que representa os dados solicitados compreender: em um processador, exemplificar um cursor de segmento para manter o rastro de uma localização dentro do documento XML; em um processador, recuperar dados em uma localização correspondente ao cursor de segmento.

13 - Método Implementado em Computador Para Gerar Documento XML, caracterizado por compreender: em um processador, receber um objeto de dados de um aplicativo; em um processador, traduzir o objeto de dados para um objeto em uma estrutura de ligação de XML; em um processador, converter o objeto na estrutura de ligação XML em um segmento XML; e gravar o segmento XML em um armazenamento de dados.

14 - Método Implementado em Computador Para Gerar Documento XML, de acordo com a Reivindicação 13, caracterizado por o objeto na estrutura de ligação XML compreender um objeto XMLBeans.

15 - Método Implementado em Computador Para Gerar Documento XML, de acordo com a Reivindicação 13, caracterizado por a gravação do segmento XML em um armazenamento de dados compreender criar um novo documento XML.

16 - Método Implementado em Computador Para Gerar Documento XML, de acordo com a Reivindicação 13, caracterizado por a gravação do segmento XML em um armazenamento de dados compreender acrescentar o segmento XML a um documento XML existente.

17 - Método Implementado em Computador Para Gerar Documento XML, de acordo com a Reivindicação 13, caracterizado por o segmento XML compreender uma pluralidade de elementos de dados e em que a gravação do segmento XML em um armazenamento de dados compreender: em um processador, gravar os elementos de dados incremental-mente.

18 - Método Implementado em Computador Para Gerar Documento XML, de acordo com a Reivindicação 13, caracterizado por pelo menos um elemento de dados do segmento XML compreender uma etiqueta de final e em que a gravação dos elementos de dados incrementalmente compreende: em um processador, remover pelo menos uma etiqueta de final para um elemento do segmento XML; em um processador, empurrar a etiqueta de final removido para uma pilha; em um processador, gravar elementos de dados filhos incrementalmente no armazenamento de dados; em um processador, rebaixar pelo menos uma etiqueta de final para o segmento XML da pilha; e em um processador, gravar as etiquetas de extremidade rebaixadas para o armazenamento de dados.

19 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, caracterizado por compreender, em um sistema de computação compreendendo um processador: em um processador, receber uma solicitação para converter um documento XML em um arquivo simples; em um processador, obter uma configuração para o arquivo simples; em um processador, recuperar pelo menos um segmento do documento XML; em um processador, converter pelo menos um segmento recuperado em uma representação baseada em objeto; em um processador, extrair pelo menos um objeto da representação baseada em objeto; e em um processador, gravar dados que representam pelo menos um objeto extraído no arquivo simples, em um formato especificado pela configuração obtida.

20 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, de acordo com a Reivindicação 19, caracterizado por ainda compreender: em um processador, responsivo ao formato especificado pela configuração obtida, derivar pelo menos um item de dados de pelo menos um segmento do documento XML; e em um processador, gravar os dados derivados no arquivo simples.

21 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, caracterizado por compreender, em um sistema de computação compreendendo pelo menos um processador: em um processador, receber uma solicitação para converter um documento XML em um arquivo simples; em um processador, obter uma configuração para o arquivo simples; em um processador, recuperar um primeiro segmento do documento XML; em um processador, converter o primeiro segmento em uma representação baseada em objeto; em um processador, receber uma indicação pelo menos uma referência cruzada entre o primeiro segmento do documento XML e um segundo segmento do documento XML; em um processador, com base na indicação de pelo menos uma referência cruzada, manter pelo menos um valor de referência cruzada extraído da representação baseada em objeto da primeira porção do documento XML na memória; em um processador, recuperar o segundo segmento do documento XML; em um processador, converter o segundo segmento em uma representação baseada em objeto; em um processador, extrair pelo menos um objeto da representação baseada em objeto da primeira porção do documento XML; em um processador, extrair pelo menos um objeto da representação baseada em objeto da segunda porção do documento XML; e em um processador, gravar dados que representam os objetos extraídos das representações baseadas em objeto das primeiras e segundas porções do documento XML em um formato de arquivo simples especificado pela configuração obtida.

22 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, de acordo com a Reivindicação 21, caracterizado por a gravação de dados que representam os objetos extraídos das representações baseadas em objeto das primeiras e segundas porções do documento XML compreender: combinar dados das primeiras e segundas porções do documento XML de uma maneira especificada pela configuração para o arquivo simples.

23 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, de acordo com a Reivindicação 21, caracterizado por a manutenção de pelo menos um valor de referência cruzada extraído da representação baseada em objeto da primeira porção do documento XML na memória compreender: armazenar cada valor de referência cruzada extraído da representação baseada em objeto da primeira porção do documento XML em uma localização de memória e identificar o valor por um codinome.

24 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, de acordo com a Reivindicação 21, caracterizado por ainda compreender: após armazenar pelo menos um valor de referência cruzada, descartando a representação baseada em objeto da primeira porção da memória.

25 - Método Implementado em Computador Para Converter Documento XML em Arquivo Simples, de acordo com a Reivindicação 21, caracterizado por ainda compreender: em um processador, responsivo ao formato especificado pela configuração obtida, derivar pelo menos um item de dados de pelo menos uma dentre a primeira e a segunda porções do documento XML; e em um processador, gravar os dados derivados no arquivo simples.

26 - Produto de Programa de Computador Para Processar Documento XML, caracterizado por compreender: um meio de armazenamento legível por computador não transitória; e código de programa de computador, codificado no meio, para fazer com que pelo menos um processador execute as etapas de: receber uma mensagem de um aplicativo solicitando dados do documento XML; responsivo a receber a mensagem: recuperar do documento XML pelo menos um segmento que representa os dados solicitados; converter pelo menos um segmento recuperado em uma representação XML baseada em objeto; e transformar a representação XML baseada em objeto em pelo menos um objeto de dados de aplicativo; e transmitir pelo menos um objeto de dados de aplicativo para o aplicativo.

27 - Produto de Programa de Computador Para Processar Documento XML, caracterizado por compreender: um meio de armazenamento legível por computador não transitória; e código de programa de computador, codificado no meio, para fazer com que pelo menos um processador execute as etapas de: receber um objeto de dados de um aplicativo; traduzir o objeto de dados para um objeto em uma estrutura de ligação XML. converter o objeto na estrutura de ligação XML em um segmento XML; e gravar o segmento XML em um armazenamento de dados.

28 - Produto de Programa de Computador Para Processar Documento XML, caracterizado por compreender: um meio de armazenamento legível por computador não transitória; e código de programa de computador, codificado no meio, para fa- zer com que pelo menos um processador execute as etapas de: receber uma solicitação para converter um documento XML em um arquivo simples; obter uma configuração para o arquivo simples; recuperar pelo menos um segmento do documento XML; converter pelo menos um segmento recuperado em uma representação baseada em objeto; extrair pelo menos um objeto da representação baseada em objeto; e gravar dados que representam pelo menos um objeto extraído no arquivo simples em um formato especificado pela configuração obtida.

29 - Produto de Programa de Computador Para Processar Documento XML, caracterizado por compreender: um meio de armazenamento legível por computador não transitória; e código de programa de computador, codificado no meio, para fazer com que pelo menos um processador execute as etapas de: receber uma solicitação para converter um documento XML em um arquivo simples; obter uma configuração para o arquivo simples; recuperar um primeiro segmento do documento XML; converter o primeiro segmento em uma representação baseada em objeto; receber uma indicação de pelo menos uma referência cruzada entre o primeiro segmento do documento XML e um segundo segmento do documento XML; com base na indicação pelo menos uma referência cruzada, manter pelo menos um valor de referência cruzada extraído da representação baseada em objeto da primeira porção do documento XML na memória; recuperar o segundo segmento do documento XML; converter o segundo segmento em uma representação baseada em objeto; extrair pelo menos um valor da representação baseada em objeto da primeira porção do documento XML; extrair pelo menos um objeto da representação baseada em objeto da segunda porção do documento XML; e gravar dados que representam os objetos extraídos das representações baseadas em objeto da primeira e da segunda porções do documento XML em um formato de arquivo simples especificado pela configuração obtida.

30 - Sistema Para Processar Documento XML, caracterizado por compreender: em um sistema de computação tendo um processador, uma estrutura para receber uma mensagem de um aplicativo solicitando dados do documento XML e para solicitar extração de um segmento XML; um analisador, comunicativamente acoplado à estrutura, para fornecer, para a estrutura, pelo menos um segmento que representa os dados solicitados; e uma camada de tradução, comunicativamente acoplada à estrutura, para: converter pelo menos um segmento recuperado em uma representação XML baseada em objeto; e transformar a representação XML baseada em objeto em pelo menos um objeto de dados de aplicativo; em que a estrutura transmite pelo menos um objeto de dados de aplicativo para o aplicativo.

31- Sistema Para Gerar Documento XML, caracterizado por compreender: em um sistema de computação tendo um processador, uma estrutura para receber um objeto de dados de um aplicativo; e uma camada de tradução, comunicativamente acoplada à estrutura, para: traduzir o objeto de dados para um objeto em uma estrutura de ligação XML; e converter o objeto na estrutura de ligação XML em um segmento XML; um armazenamento de dados, comunicativamente acoplado à estrutura, para armazenar o segmento XML.

32- Sistema Para Converter Documento XML em Arquivo Simples, caracterizado por compreender: em um sistema de computação tendo um processador, uma estrutura para receber uma solicitação para converter um documento XML em um arquivo simples; um configurador, comunicativamente acoplado à estrutura, para transmitir para a estrutura uma configuração para o arquivo simples; um analisador, comunicativamente acoplado à estrutura para, com base na configuração, recuperar pelo menos um segmento do documento XML; uma camada de tradução, comunicativamente acoplada à estrutura para converter pelo menos um segmento recuperado em uma representação baseada em objeto; em que a estrutura extrai pelo menos um objeto da representação baseada em objeto; e um armazenamento de dados, comunicativamente acoplado à estrutura, para armazenar pelo menos um objeto extraído em um arquivo simples, em um formato especificado pela configuração obtida.