Estou em uma ponta solta sobre como adicionar um anexo no meu pedido SOAP. Nós temos que consumir um serviço da Web do partido thrid, construído em java, que é a coisa mais complicada que eu já encontrei. Quaisquer outros serviços da Web que usamos, os anexos necessários, têm um método ou propriedade para adicionar o anexo. Simples. No entanto, este não fornece esse método. Temos uma versão da mensagem SOAP juntos que é exatamente como queremos o XML, no entanto, é a parte MIME do arquivo que não podemos adicionar. Esta é a parte XML que podemos gerar e enviar, no entanto, é incorreto, pois precisamos de uma parte MIME em lá como: Eu tenho vasculhado a internet para respostas, mas vieram em branco. Não parece haver muita documentação sobre como usar o WSE para isso. Devo salientar que o WSE é um requisito no lado do servidor, e não há nenhuma maneira que eu possa mudar a tecnologia para resolver esse problema. Existe uma maneira que essas seções MIME pode ser adicionado EDIT: Devo acrescentar que eu posso obter um documento XML de trabalho enviado através de SoapUI com anexos, mas não consigo encontrar uma maneira dentro do nosso código. Eu adicionei um bounty para tentar e obter uma solução para este problema. Se alguém tem alguma outra idéia, por favor me avise. EDIT novamente: Eu sei que tem sido uma semana desde que eu era capaz de verificar as respostas aqui, mas enquanto alguns dão uma boa idéia onde olhar ainda estou desenhando um espaço em branco. A documentação terrível que rodeia XopDocument e seus métodos é um grande ponto de aderência, se alguém tem algum exemplo de usar SaveToXopPackage eles poderiam fornecer, porque isso está começando a grate perguntou 20 de dezembro às 11:48 Bem, John, como sobre chegar a uma solução Ao invés de ir ao redor apenas fingindo que você sabe tudo. Neste cenário, para mim, o WSE IS é necessário. Sem ele, nossos pedidos serão rejeitados. Eu não posso dizer o vendedor de terceiros como eles devem ser codificação, eu posso tentar, mas eles sempre foram a empresa menos útil no mundo para contornar. Assim, enquanto o WSE não deve ser usado se você estiver criando seu próprio software, é um requisito neste caso. Eu tenho pouco a dizer sobre isso, exceto que eu espero que alguém tenha dito ao Imperador suas roupas são obsoletas. Além disso, se você fingir que usar o WSE não é uma opção, então você certamente aprenderá a personalizar o WCF para fazer o que você precisa, apenas usando o software suportado. Ndash John Saunders Jan 5 12 às 17:53 Eu acho que você pode ter um par de opções: 1) Use MTOM. Isso parece automaticamente quebrar a mensagem de saída em blocos MIME. 2) A Microsoft realmente fornece suporte para gerar e ler XOP com mime através da classe XopDocument, que é o que SoapEnvelope herda de. No entanto, eu acho que essa abordagem pode exigir que você execute o envio da mensagem você mesmo através de um HttpWebRequest. Este blog tem um exemplo de como implementar isso. A desvantagem é que isso requer um monte de código extra e configuração, a fim de funcionar corretamente. A solução ideal seria interceptar o código que executa a transmissão do envelope, mas não consegui localizar o local correto para isso no pipeline. Im 90 confiável Im trabalhando no mesmo projeto exato como vocês. Esse pedido de sabão é um pouco familiar demais :-) Weve conseguiu a maior parte do caminho lá, alternando para WCF e basicamente mão-codificação do objeto pedido (criando classes que correspondem ao formato de sabão e, em seguida, usando xmlelement atributos para decorá-lo para que ele Parece o seu pedido de sabão. O arquivo em si é declarado como um Byte () na classe Attachment e também decorado com o xmlelement). Heres o que o WCF contrato e parte do modelo de dados parece. O modelo de dados real tem um monte de classes extras (Área de Aplicação, Área de Dados, Trabalho, etc), mas isso dá-lhe o suficiente de uma sensação de como é estruturado. A parte importante é o Arquivo como Byte (). Aqui está em Vb. Em seguida, você tem seu cliente WCF, este é praticamente o mesmo que todos os clientes WCF. Finalmente você tem o app. config. Heres a magia porque estavam dizendo WCF para usar Mtom para enviar a mensagem. Isso levará o Byte () e retirá-lo em uma seção MIME separada substituindo-o por um XOP: Include. Note que por agora estou apenas enviando-o através de localhost para que eu possa ver o pedido usando tcpTrace. Você pode google que app, mas itll basicamente capturar o pedido para que possamos ver como ele olha. Eu configurar tcpTrace para ouvir na porta 84. Finalmente, heres a chamada real para o cliente WCF para fazer a solicitação. E heres o rastro que nós começamos através de tcpTrace. Seu obteve a direita direita da estrutura e seu controlado puxar os dados binários fora do xml e colocá-lo em uma seção separada de MIME. Como mencionei anteriormente - ainda temos alguns problemas. Existem algumas marcas em falta no Cabeçalho do Sabão. Mas eu acho que bem ser capaz de descobrir aqueles. O verdadeiro problema é que o Content-ID não está em um formato que nosso parceiro pode aceitar - eles esperam algo como lt1.a33c2d7e84634122705ebc71e53d95d4c2683d726ba54e14apache. org e está formatando-os como tempuri. org1634618782531246992. Isso está fazendo com que seu manipulador de serviço da Web falhe porque ele não sabe ler os índices de conteúdo escapados dentro da mensagem de sabão. Respondeu Jan 7 12 at 0:23 Apenas notou sua edição para este agora. Sim, parece exatamente o mesmo projeto Infelizmente sua solução não vai funcionar em nosso caso, pois estamos restritos a usar o WSE e não o WCF. Depende do VS 2005. É uma dor. Mas este é o resultado que eu estou procurando, mas precisa descobrir a solução em WSE. (No entanto, com o seu problema, você não pode definir o Content-ID para qualquer coisa que você quer Isso funciona dentro SoapUI, quando você especificar o conteúdo-ID-se e não depender da representação padrão Meu endereço de e-mail, não um trabalho, está no meu Se você quiser conversar mais adiante se você quiser conversar mais ... Como você diz que você tem que trabalhar com SoapUI, eu acho que você pode apenas pedir SoapUI para o XML gerado enviou para que você saiba como ele deve olhar, então Modificar o seu código para imitar isso UPDATE: após o seu comentário e ler as outras respostas em mais detalhes: a solução parece-me apenas enviar bytes diretamente, usando HttpWebRequest como em resposta ktsioliss. Por detalhe: Crie o seu SOAP XML (o exemplo que você deu ), Codifique isso para bytes em UTF8 (1) Crie uma string com o mimeboundary inicial (a parte em seu Antes de XML), codifique para bytes em UTF8 (2) Crie os bytes para o segundo mimeboundary (a parte em depois de XML). Então crie a string contendo --MIMEBOUNDARY etc. codifique para UTF8 bytes, e acrescentar todos os bytes do seu arquivo test. gif (3) Acrescentar todos os bytes na ordem (2), (1) e (3) e enviá-los através do fio. Não deveria fazer o truque Ok, então eu tenho que aceitar os dados do arquivo no elemento ltgwm: Filegt. Isso é sem usar o XOP, então o pedido agora se parece com: Quando passado para SoapUI isso funciona perfeitamente, no entanto, no código ele dá uma resposta, mas ele lança um erro dizendo resposta não é XML bem-formado. Com uma exceção interna de WSE1608: Não XOP partes foram localizadas no fluxo para o conteúdo-id especificado: ltrootpart36875c60-630c-4e23-9e74-f9a9c7547fc7example. jaxws. sungt Vou abrir uma nova pergunta sobre isso, uma vez que é tecnicamente um diferente questão. Estou envolvido em exatamente o mesmo projeto e tenho os mesmos problemas como discutido neste tópico Estou usando o vb 2005 e aprimoramentos do WSE 3.0 e eu tenho que trabalhar mesmo é uma dor para agora. Ao escrever o conteúdo do arquivo diretamente na propriedade de arquivo, o anexo será aceito pelo parceiro. No meu caso, isso funciona para quase todas as transações, exceto PRAs. Aqui, a resposta é positiva e um AttachmentID será entregue, mas o anexo não aparece na transação. Aqui está um exemplo da seção de anexo: Se eu definir RequireMtom para o serviço para True, eu obter o seguinte erro: Das Prfix kann nicht von in starstandards. orgwebservices200510transport innerhalb desselben Startelementtags neu definiert werden. Por um lado, funciona, por outro lado, não tenho certeza se ele será enviado com elementos XOP. Respondeu Jan 17 12 at 12:46 Eu tinha uma discussão com os desenvolvedores de serviços da web sobre colocar os dados diretamente no elemento ltFilegt e eles disseram que isso não está de acordo com suas especificações e eles exigem um elemento ltxop: Includegt. Veja stackoverflowquestions8805095hellip para uma descrição mais detalhada do problema que estamos tendo. Se você quiser discutir mais além aqui, por favor, veja meu perfil para o meu endereço de e-mail. Ndash anothershrubery Jan 17 12 em 12:59 Claro. Mas não consigo encontrar seu endereço de e-mail. Ndash Daniel Schlieckmann Jan 17 12 às 15:43 Se você can39t vê-lo em bio, agora está na seção About Me no meu perfil. Ndash anothershrubery Jan 17 12 at 15:45 Obrigado. Mandei-lhe um e-mail. Ndash Daniel Schlieckmann Jan 18 12 às 15:24 Sua resposta 2017 Stack Exchange, IncUsando SOAP para enviar dados binários Nosso exemplo de mensagens até à data tem sido bastante pequeno, mas podemos imaginar facilmente querer usar SOAP para enviar grandes blocos binários de dados. Por exemplo, considere uma reivindicação de seguro automatizada. Os agentes remotos podem usar o software SOAP para enviar novas reivindicações a um servidor central e parte dos dados associados a uma reivindicação podem ser imagens digitais gravando danos ou o ambiente em torno de um acidente. Uma vez que XML can039t codificar diretamente verdadeiros dados binários de 8 bits no momento, uma maneira simples de fazer esse tipo de coisa pode ser usar o tipo XML Schema base64binary e codificar suas imagens como texto base64 dentro do XML: Esta técnica funciona, mas it039s não Particularmente eficiente em termos de largura de banda, e leva tempo de processamento para codificar e decodificar bytes de e para base64. O e-mail tem usado o padrão Multipurpose Internet Mail Extensions (MIME) há algum tempo para fazer esse trabalho e o MIME permite a codificação de binários de 8 bits. MIME também é a base para alguns dos dados codificados utilizados em HTTP desde software HTTP geralmente pode lidar com MIME, pode ser bom se houvesse uma maneira de integrar o protocolo SOAP com este padrão e uma maneira mais eficiente de enviar dados binários. SOAP com anexos e DIME No final de 2000, a HP e a Microsoft lançaram uma especificação denominada quotSOAP Messages with Attachments. quot A especificação descreve uma maneira simples de usar a codificação multiref no SOAP 1.1 para referenciar peças codificadas em MIME. Nós won039t entrar em muito detalhe aqui se você quiser ler a especificação, você pode encontrá-lo em w3.orgTR2000NOTE-SOAP-anexos-20001211. A idéia básica por trás do SOAP com Attachments (SwA) é que você usa o mesmo truque HREF que viu na seção QuotObject Graphs para inserir uma referência aos dados na mensagem SOAP em vez de codificá-la diretamente. No caso SwA, no entanto, você usa o conteúdo-id (cid) da parte MIME que contém os dados que você está interessado como referência em vez da ID de algum XML. Assim, a mensagem codificada anteriormente seria algo assim: Outra tecnologia chamada Direct Internet Message Encapsulation (DIME). Da Microsoft e da IBM, usou uma técnica semelhante, exceto que a codificação on-the-wire era menor e mais eficiente do que MIME. DIME foi submetido ao IETF em 2002, mas desde então perdeu o apoio de seus autores originais. Swa e DIME são grandes tecnologias, e eles conseguem fazer o trabalho, mas existem alguns problemas. A principal questão é que tanto SwA e DIME introduzir uma estrutura de dados que está explicitamente fora do domínio do modelo de dados XML. Em outras palavras, se um intermediário recebeu a mensagem MIME anterior e queria assinar ou criptografar digitalmente o corpo SOAP, precisaria de regras que contassem como o conteúdo do anexo MIME estava relacionado ao envelope SOAP. Essas regras não foram formalizadas para a Swadime. Portanto, ferramentas e software que trabalham com o modelo de dados XML precisam ser modificados para entender a estrutura de empacotamento SwADIME e ter uma maneira de acessar os dados incorporados nos anexos MIME. Vários visionários de XML e de serviço da Web começaram a discutir a questão geral da fusão de conteúdo binário com o modelo de dados XML em serio. Como resultado, várias propostas estão agora a evoluir para resolver este problema de uma forma arquitectonicamente mais limpa. PASWA, MTOM e XOP Em abril de 2003, o aditamento do Infoset Adicional ao SOAP com Anexos (PASWA) g documento foi lançado por várias empresas, incluindo Microsoft, ATampT e SAP. PASWA introduziu um modelo lógico para incluir conteúdo binário diretamente em um infoset SOAP. Fisicamente, as mensagens que PASWA lida com olhar quase idêntico aos nossos dois exemplos anteriores (a imagem codificada primeiro como base64 inline com o XML e, em seguida, como um anexo MIME) a diferença está em como pensamos sobre os anexos. Em vez de pensar na imagem codificada em MIME como uma entidade separada que é explicitamente referida no envelope SOAP, nós lógicamente pensamos nela como se ela ainda estivesse em linha com o XML. Em outras palavras, o empacotamento MIME é uma otimização e as implementações precisam garantir que os processadores que olham para o modelo de dados SOAP para fins de criptografia ou assinatura ainda vejam os dados reais como se fossem codificados em base64 no XML. Em julho de 2003, após uma longa série de conversas entre o XML Protocol Group e os apoiadores do PASWA, nasceu o Message Transmission Optimization Mechanism (MTOM) g, de propriedade do grupo XMLP. Ele reformulou as idéias em PASWA em um recurso abstrato para melhor sincronização com o modelo de extensibilidade SOAP 1.2 e, em seguida, ofereceu uma implementação desse recurso sobre HTTP. O mecanismo de serialização é chamado XML-Binary Optimized Packaging (XOP) g ele foi levado em conta em uma especificação separada para que ele também poderia ser usado em contextos não-SOAP. Como exemplo, modificamos ligeiramente a reivindicação de seguro anterior aumentando o XML com um atributo de tipo de conteúdo (da especificação XOP) que nos diz qual tipo de conteúdo MIME usar ao serializar esse infoset usando XOP. Here039s a nova versão: Uma versão MTOMXOP de nossa reivindicação de seguro modificado se parece com isto: Essencialmente, it039s o mesmo no fio como a versão SwA, mas ele usa o xop: Includegt elemento em vez de apenas o atributo href. A diferença real é arquitetônica, já que imaginamos que as ferramentas e APIs manipularão essa mensagem exatamente como se fosse um modelo de dados XML. MTOM e XOP estão a caminho de serem lançados pelo XML Protocol Working Group algum tempo em 2004, e continua a ser visto como eles serão bem aceitos pela comunidade de usuários mais amplo. O feedback inicial foi muito positivo, porém, e os autores deste livro estão por trás da idéia de um modelo de dados unificado para XML e conteúdo binário. Anexos com aplicativos SOAP SOAP muitas vezes têm de lidar com mais do que apenas mensagens simples. A carga útil para uma mensagem SOAP geralmente pode incluir um processamento de texto ou documento PDF, imagem ou outro arquivo binário. Este artigo explica como usar o Message Transmission Optimization Mechanism (MTOM) para enviar e receber essas mensagens. Baixar este guia gratuito Manual gratuito: Desenvolvimento de aplicativos Java na nuvem Os engenheiros de software estão se aproximando do desenvolvimento e do design corporativo de uma maneira inteiramente nova, graças à nuvem. Neste manual especializado, explore como seus colegas estão aproveitando a nuvem para agilizar o gerenciamento do ciclo de vida do aplicativo, economizar dinheiro e tornar a produção e a segurança mais eficientes. Ao enviar suas informações pessoais, você concorda que a TechTarget e seus parceiros podem entrar em contato com você sobre conteúdo relevante, produtos e ofertas especiais. Você também concorda que suas informações pessoais podem ser transferidas e processadas nos Estados Unidos e que você leu e concordou com os Termos de Uso e com a Política de Privacidade. Pré-requisitos Este artigo usa o WSO2 Web Services Application Server (WSAS). É recomendável que você baixar e instalar WSO2 WSAS 2.0. O artigo usa a edição de servlet instalada no Apache Tomcat. Qualquer servidor de aplicação pode ser usado com a versão servlet, basta seguir as instruções de instalação incluídas com WSO2 WSAS. Você não tem que usar um servidor de aplicativos em tudo, como WSO2 WSAS funciona muito bem em um formato autônomo. WSO2 WSAS requer Java 1.4 ou 1.5 mas não existem outros pré-requisitos para ele. Claro que os serviços web e SOAP especialmente é usado, assim familiaridade com isso vai ajudar. Quando XML não é suficiente: dados binários Existem inúmeras maneiras de enviar dados pela rede. Existem inúmeros protocolos e formatos de dados. A padronização em torno do SOAP eliminou um monte de conjecturas ao enviar dados entre sistemas. SOAP padroniza o protocolo (HTTP) eo formato de dados (XML.) Uma das principais críticas do SOAP é o uso do XML. O XML é baseado em texto. Isto não só faz para grandes mensagens, mas torna incompatível com dados binários. Por exemplo, vamos dizer que sua mensagem precisa incluir uma imagem. Isso representa um problema quando o formato da mensagem é texto. Combinando dados binários com SOAP Ok, então você precisa enviar dados binários entre aplicativos. Você gostaria de usar SOAP, mas é limitado ao texto. Então você deve simplesmente desistir de SOAP todos juntos Claro que não, existem muitas vantagens para SOAP. Você só precisa de uma maneira de combiná-lo com dados binários. Você vê páginas da web fazer isso o tempo todo não pode ser tão difícil, certo Vamos explorar algumas soluções para este problema. Uma maneira que você pode tentar é simplesmente despejar o binário em um nó de texto. Pode parecer algo como a Listagem 1. Listagem 1. XML com dados binários: Primeira tentativa Lembre-se que os caracteres também são bytes, assim como os dados binários. Um analisador XML, seja um analisador DOM, SAX ou StAX, deve usar a codificação de conjunto de caracteres do documento para interpretar todos os bytes no documento como caracteres. Assim, nossos dados binários poderiam facilmente ter caracteres que correspondem a caracteres XML reservados, como lt ou gt ou amp. Qualquer sequência de bytes tal no nó de texto acima fará com que o analisador no outro lado para quebrar. Portanto, essa abordagem não funcionará. Mas espere, talvez haja uma maneira de corrigir essa abordagem. E sobre como usar um bloco CDATA Que irá dizer o analisador para ignorar os caracteres dentro do bloco. Esta abordagem modificada pode parecer a Listagem 2. Listagem 2. XML com Binário: Usando CDATA Agora, se tivermos bytes que seriam interpretados como gt (por exemplo,) eles serão ignorados. No entanto, o analisador tem de descobrir onde termina a secção CDATA. Ele faz isso procurando a seqüência de bytes correspondente aos caracteres gt. Pode parecer improvável, mas nossos dados binários poderiam ter apenas uma seqüência de bytes no meio dela. Isso faria com que qualquer analisador pensasse que a seção de CDATA tinha terminado e os caráteres subseqüentes seriam interpretados apenas como em nossa primeira tentativa. Então isso não vai funcionar também. Precisamos de uma maneira de garantir que esses bytes não sejam interpretados. Base 64 de codificação: funciona, mas inchado Existe uma solução para esta variante do nosso problema. Uma maneira comum de fazer isso é usar a codificação Base 64. Esta técnica tem sido em torno (como um padrão) desde os anos 80. Envolve o uso de um alfabeto de 64 caracteres, consistindo dos caracteres minúsculos, a-z, os caracteres maiúsculos, A-Z, os números 0-9 e os símbolos e. Cada byte é mapeado para esses caracteres, então não há nenhuma maneira para qualquer byte para ser mal interpretado como qualquer coisa que iria sufocar um analisador XML. Então, problema resolvido, certo Sim, mas é uma solução bastante ineficiente. Os ventos binários codificados na base 64 são, em média, 37 maiores (número de bytes) do que os dados binários não codificados não processados. Além disso, o analisador no outro lado precisa saber sobre a codificação para que ele possa decodificar a carga útil. Poder-se-ia imaginar que se a codificação Base 64 fazia parte do padrão SOAP, então haveria alguma maneira padrão de indicar esses processadores de mensagens SOAP. No entanto, este não é o caso. Pode ser uma solução, mas é ineficiente e não-padrão. Precisamos de algo mais eficiente e padronizado. SOAP com anexos: Obras mas design falho Uma solução para o problema é usar o que é conhecido como SOAP com anexos. A idéia aqui é apenas colocar os dados binários fora da mensagem SOAP completamente. A Figura 1 fornece uma visualização agradável disso. Figura 1. SOAP com anexos Isso é muito semelhante ao modo como os arquivos binários podem ser anexados aos e-mails. A mensagem SOAP contém uma referência para o arquivo binário anexado à mensagem. Isso é mais eficiente e padronizado, mas tem algumas falhas no seu design. O anexo binário não faz parte da mensagem SOAP. É semelhante em muitas maneiras de apenas passar um URI para os dados binários e deixá-lo até o processador de mensagens para recuperar os dados binários reais. Ele apresenta alguns problemas reais para coisas como WS-Security. Ainda assim, isso é o que foi usado por um tempo, até que uma solução melhor foi proposta: MTOM. MTOM: Melhor de ambos os mundos MTOM significa mecanismo de optimização de transmissão de mensagens SOAP. Ele combina a eficiência do SOAP com anexos, mas ele faz isso sem ter que quebrar os dados binários fora da mensagem SOAP. Como isso pode ser A chave é uma tecnologia chamada XML-binário Optimized Packaging ou XOP. XOP permite que os dados binários sejam incluídos como parte do Infoset XML. Na verdade, o Infoset XML torna-se um superconjunto do Infoset tradicional conhecido como o XOP Infoset. Ele permite que os dados binários sejam armazenados fora do documento XML, assim como no SOAP com anexos. Ele usa um XOP especial: incluir elemento para dizer ao processador para substituir o conteúdo com os dados binários referenciados, encapsulando assim a lógica de armazenamento discreto e recuperação dos dados binários. Essa lógica torna-se inerente ao analisador XML e permite que o analisador SOAP trate os dados binários como parte do documento XML, sem lógica de recuperação especial. Da mesma forma, permite que um servidor SOAP crie uma mensagem SOAP de maneira uniforme, sem lógica especial para quebrar os dados binários da mensagem SOAP. MTOM em WSO2 WSAS Weve falou muito sobre a necessidade de MTOM e como ele deve trabalhar em teoria. Não nos faz muito bem sem uma implementação real. Felizmente theres uma maneira fácil de obter uma implementação MTOM grande, basta usar WSO2 WSAS. WSO2 WSAS é construído em cima de tecnologias testadas e verdadeiras, incluindo Apache Axis2. Axis2 dá WSO2 WSAS sua implementação MTOM. Vamos dar uma olhada em como aproveitar o poder da implementação MTOM WSASAxis2s. Enviar uma mensagem MTOM de um serviço Web com o Axiom API O suporte MTOM no Axis2 baseia-se nas mesmas classes utilizadas no Axis2. Ele usa Axis2s Object Model (OM). Axis2 suporta a codificação Base 64 e MTOM, e torna relativamente simples alternar entre eles. Por que Bem para arquivos muito pequenos, pode realmente ser mais eficiente usar a codificação Base 64. Para conseguir essa troca perfeita entre transporte otimizado e não otimizado, o Axis2 trata os dados binários como um nó de texto XML. A única diferença é que você precisa passar um javax. activation. DataHandler para acessar os dados, como mostrado na Listagem 3. Listagem 3. Adicionando Dados Binários com a API do Axiom No exemplo na Listagem 3, um javax. activation. FileDataSource É usado para fornecer o DataHandler com acesso aos dados binários. Você pode usar qualquer classe que implemente a interface javax. activation. DataSource. Por exemplo, ao trabalhar com imagens, o org. apache. axis2.attachments. ImageDataSource pode ser usado. Ele implementa a interface DataSource e pode ser mais conveniente ao trabalhar com imagens. Então, como é que Axis2 e, portanto, WSO2 WSAS, sabem usar o MTOM para otimizar os dados binários? Isso é realmente o que o Axis2 fará por padrão. Você pode substituir manualmente isso adicionando apenas uma linha de código, como mostrado na Listagem 4. Listagem 4. Desativando o MTOM Essa única linha de código dirá ao Axis2 para não otimizar, ou seja, não usar o MTOM. Assim, o Axis2 usará a codificação Base 64 dos dados binários e será realmente um nó de texto. Caso contrário, o MTOM iniciará e um XOP será usado para otimizar o transporte dos dados binários dentro da mensagem SOAP. Habilitando MTOM no servidor É claro que para obter todo esse comportamento maravilhoso, automaticamente otimizado, você precisa habilitar o MTOM. Você pode fazer isso através de seu arquivo axis2.xml com muita facilidade, como mostrado na Listagem 5. Listagem 5. Ativando o MTOM no axis. xml Não é possível obter mais indolor que isso, direito Esta é uma configuração global e é a configuração padrão no WSO2 WSAS. Você pode realmente habilitar o MTOM em quatro níveis diferentes: global, grupo de serviços, serviço e operação. Você usa a mesma semântica para cada nível. Você pode usar o Console de Gerenciamento para gerenciar o MTOM em cada um desses níveis. Por exemplo, dê uma olhada na Figura 2. Figura 2. Gerenciando o MTOM no Nível do Grupo de Serviço Aqui nós vemos o MTOM sendo gerenciado no nível do Grupo de Serviço. Cada serviço do grupo também pode ser gerenciado individualmente, como mostrado na Figura 3. Figura 3. Gerenciando MTOM no nível de serviço É claro que cada serviço pode ter uma ou mais operações. WSAS permite que você gerencie MTOM nesse nível também, como mostrado na Figura 4. Note que em cada nível, o MTOM tem três valores possíveis: true, false e optional. Se a propriedade for definida como verdadeira, o serviço enviará uma mensagem otimizada quando for necessário, ou seja, quando os dados binários forem incluídos. Se o valor estiver definido como false, então a otimização nunca será usada ea codificação Base 64 será usada para quaisquer dados binários. Se for definido como opcional, o WSAS otimizará se e somente se a solicitação foi otimizada. O tipo de solicitação indicará à WSAS se deve usar MTOM ou não. Por que precisamos desse tipo de flexibilidade Como mencionado anteriormente, é freqüentemente vantajoso usar a codificação Base 64 em arquivos pequenos. Assim, você pode decidir que certas operações devem usar MTOM e outros não. Ou você pode torná-lo opcional em uma operação, programaticamente fazer uma verificação para o tamanho dos dados sendo enviados e, em seguida, optar por substituir o padrão MTOM se o arquivo for pequeno. Então você está enviando MTOM. Vamos dar uma olhada em como WSAS torna fácil para enviar uma mensagem MTOM de um cliente de serviço da web. Criando um cliente SOAP que envia mensagens MTOM Enviar uma mensagem MTOM de um cliente é tão fácil quanto enviar uma mensagem MTOM de um serviço da Web. O Axis2 fornece várias APIs convenientes. Um exemplo é mostrado na Listagem 6. Listagem 6. Código de cliente para o envio de mensagem MTOM Como você pode ver na Listagem 6, a principal coisa a fazer é habilitar o MTOM em opções para o cliente de serviço web. Depois de fazer isso, o Axis2 otimizará automaticamente todos os dados binários enviados para o serviço da Web usando o MTOM automaticamente. Vimos como enviar mensagens MTOM a partir de um serviço web e para um serviço web, agora vamos olhar para como trabalhar com dados que foi enviado usando MTOM. Tratamento de uma mensagem MTOM em um serviço da Web Agora vamos supor que você tenha um serviço da Web que aceita dados binários como parte de uma mensagem SOAP de um cliente. Se o seu serviço Web estiver em execução no WSAS, você não precisa fazer nada de especial para ser capaz de lidar com dados binários otimizados de seus clientes. Seus clientes podem enviar mensagens SOAP que usam a codificação MTOM ou Base 64. Seu tudo sem emenda com WSAS. A Listagem 7 mostra um exemplo de recebimento de dados otimizados. Lista 7. Serviço da Web recebendo SOAP Otimizado Como vimos anteriormente, a API do Axiom trata os dados binários como um nó de texto. Isso permite uma única API para lidar com dados otimizados e não otimizados (Base 64 codificados). Você simplesmente acessar o DataHandler associado ao nó de texto (que contém os dados binários) e usar isso para obter um InputStream. Depois de ter o InputStream, você pode ler todos os bytes e processá-los no entanto você precisa. O WSAS facilita a manipulação de mensagens SOAP com cargas úteis de dados binários otimizados. Vamos dar uma olhada em como é fácil trabalhar com MTOM em clientes. Manipulação de uma mensagem MTOM em um cliente Não há nenhuma mágica para lidar com uma resposta de serviço da Web MTOM. Já vimos como configurar o pedido. Na Figura 8 você verá como lidar com uma resposta que contém dados binários otimizados com MTOM. Novamente a chave aqui é usando o Axiom API. Ele nos permite tratar os dados binários como um nó de texto e, em seguida, usar o DataHandler para obter um InputStream para os dados. Novamente, uma vez que você tenha o InputStream, você pode processar os dados no entanto você precisa. Nós vimos como MTOM fornece a combinação perfeita de padronização SOAP e eficiência para o transporte de dados binários dentro de uma mensagem de serviço web. Já vimos como WSO2 WSAS implementa a especificação MTOM usando Axis2. Fizemos um exame de como configurar os servidores de serviços da Web e os clientes para enviar e receber mensagens MTOM otimizadas. Agora temos tudo o que precisamos para adicionar dados binários aos nossos serviços web usando WSO2 WSAS. Você vai querer baixar WSO2 WSAS. Leia sobre os recursos mais recentes do WSO2 WSAS 2.0. Aprenda e interaja com a comunidade WSO2 no WSIS Wiki. Saiba como expor seus serviços como serviços da Web facilmente com o Axis2. Saiba como o Axis2 pode ativar seus designs SOA no artigo SOA do developerWorks com Axis2. Saiba tudo sobre a interoperabilidade do Eixo com outras implementações de serviços da Web nesta entrada no blog TSS Interoperability. Mergulhe na API AXIOM no artigo do developerWorks Obtenha o máximo do processamento XML com o AXIOM. Leia tudo sobre XOP e MTOM nesta entrada de blog por Mark Nottingham. Interoperabilidade é o nome do jogo quando se trata de serviço web, para aprender sobre como usar MTOM com no artigo Enviando arquivos em pedaços com MTOM Web Services e 2.0. Sobre o Autor Michael Galpin é um arquiteto no eBay em San Jose, CA. Ele está desenvolvendo software desde 1998, e possui um diploma em matemática do Instituto de Tecnologia da Califórnia.
No comments:
Post a Comment