XML-binary Optimized Packaging
A especificação XOP (XML-binary Optimized Packaging) foi padronizada pela W3C (World Wide Web) em 25 de janeiro de 2005. O SOAP MTOM (Message Transmission Optimization Mechanism) utiliza XOP no contexto de SOAP e MIME sobre HTTP.
O XML é amplamente utilizado para transferência de dados. XML é um formato conhecido para troca de documentos bem formados porque é um texto simples, legível e estruturado. Por exemplo, o sistema de mensagens SOAP em serviços da Web é baseado em XML (ou é baseado no XML Infoset com SOAP 1.2). As pessoas desejam empregar formatos legados, como PDF, GIF, JPEG e similares, ao mesmo tempo que utilizam um modelo XML. O desejo de integrar XML com formatos de dados pré-existentes tem persistido há longo tempo para a comunidade XML. Geralmente, os usuários desejam empregar as convenções estruturadas de marcação extensível de XML sem abandonar formatos de dados existentes que não adotam prontamente a sintaxe XML 1.0.
À medida que o sistema de mensagens SOAP em serviços da Web se torna mais frequente, a próxima etapa é como enviar dados não baseados em texto, como imagens e dados do fluxo de trabalho, junto com sua mensagem. Por exemplo, você pode querer enviar um documento escaneado no formato .jpeg entre dois aplicativos. Surge a dúvida se esses dados podem ser compreendidos entre os diversos aplicativos.
A maioria do valor de XML e de serviços da Web reside na capacidade de usar ferramentas XML genéricas para trabalhar com conteúdo. Muitas ferramentas XML e padrões para descrever e manipular XML (tais como analisadores, XPath, XQuery, XSLT, criptografia XML e assinatura digital e esquema XML) não são projetados para trabalhar com dados não relacionados a texto, tais como imagens. Essas ferramentas XML não funcionam com conteúdo não XML; elas requerem texto. O desafio é como os dados não relacionados a texto (também chamados de dados binários) podem ser integrados ou anexados a XML. Ou seja, é necessária uma forma de anexar um arquivo binário a uma mensagem SOAP.
A codificação é a única maneira de ajustar os dados binários diretamente no XML. Normalmente, você pode integrar dados binários em um documento XML, codificando-o como texto utilizando Base 64. Base 64 é uma serialização que existe há algum tempo, pode ser facilmente implementada, pronta para uso, e possui interoperabilidade entre as plataformas. O tipo de dados xsi:base64binary suporta essa serialização no Esquema XML. A Base 64 codifica seus dados binários em uma representação textual que pode entrar em um documento XML. A Base 64 pega os dados binários e os converte em uma série de caracteres ASCII, codificando três octetos de uma só vez. Como cada octeto consiste em oito bits, representando-os como quatro caracteres imprimíveis no padrão ASCII, ele utiliza 64 caracteres ASCII para representar o binário. Todas as plataformas podem decodificar e codificar utilizando essa conversão. O ASCII de 6 bits é amplamente suportado e não é necessário lidar com nenhum caractere especial. Entretanto, existe um impacto de desempenho para mensagens maiores.
Para aplicativos que requerem uma operação rápida, a Base 64 pode não ser a solução. Se desejar indexar esse conteúdo, consultá-lo, transformá-lo, criptografá-lo, assiná-lo ou descrevê-lo, precisará usar um mecanismo diferente.
A primeira especificação de anexo conhecida como SwA (SOAP with Attachments) foi desenvolvida. A ideia básica de SwA é que a parte de mensagem binária (o anexo) é considerada um anexo MIME (Multipurpose Internet Mail Extensions). MIME é uma especificação amplamente implementada para formatar anexos de mensagens de correio não ASCII. O SwA especifica que o corpo SOAP pode conter uma referência à parte da mensagem MIME (o anexo) simplesmente utilizando um URI. A parte binária é anexada por uma referência.
- O SwA falha em sua usabilidade ou interoperabilidade. A infra-estrutura do SOAP foi criada em torno do envelope SOAP, que não funcionou bem para os anexos. Um anexo utilizando SwA significa que dois modelos de dados são utilizados em uma única mensagem. Esses dois modelos de dados não operam com a tecnologia XML existente.
- O SwA não funciona com o caractere de composição do SOAP. Basicamente, os padrões, como o WS-Security, não foram escritos para trabalhar com anexos. O WS-Security precisa trabalhar com todos os dados que precisam ser assinados ou criptografados digitalmente e isso significa que todos os dados no anexo também. Mas se ele não puder acessá-los, então não funcionará e a assinatura será efetivamente inválida.
Geralmente, os usuários querem deixar seus formatos não XML existentes no estado em que se encontram, para serem tratados como sequencia opacas de octetos por ferramentas e infra-estrutura XML. Essa abordagem permite que formatos amplamente utilizados, como .jpeg e .wav, coexistam harmoniosamente com o XML. O XOP torna um pouco mais realística o uso de dados codificados por base64. Atualmente, o XOP permite que apenas dados codificados com base64 sejam otimizados.
A utilização de XOP significa que as instâncias de base64Binary do tipo XML, se ativadas, são transportadas utilizando anexos MIME. Se o XOP estiver sendo utilizado, a implementação poderá codificá-la automaticamente. O XOP mantém o modelo de dados da mensagem XML porque o anexo é tratado como dados codificados por base64. Se uma pilha XML compreender a codificação XOP, seu aplicativo não precisará ser alterado. Por exemplo, quando desejar acessar uma figura .jpeg, o valor do caractere do conteúdo poderá ser obtido como uma cadeia codificada por base64.
O XOP permite que as pessoas projetem mensagens MIME, em uma troca de dados, com as quais se sintam familiarizados e que já utilizam para muitos outros dados. O formato XOP utiliza o MIME de várias partes para possibilitar a inclusão de dados binários brutos em um documento XML 1.0 sem recorrer à codificação base64.
Uma especificação complementar, MTOM (SOAP Message Transmission Optimization Method), especifica como ligar esse formato ao SOAP. Os padrões XOP e MTOM devem aprimorar o desempenho do SOAP 1.2. O XOP e o MTOM fornecem a abordagem preferida para misturar dados binários com XML baseado em texto. Acoplados, o MTOM e o XOP possibilitam a seleção de partes da mensagem que precisam ser enviadas por meio da ligação como binárias, ao mesmo tempo que mantêm o Infoset. Esses padrões possibilitam anexar dados binários fora do envelope SOAP como uma parte da mensagem. Entretanto, diferente do SwA, os dados binários são tratados do mesmo modo como eram no envelope SOAP, significando um Infoset.
O XOP define um mecanismo de serialização para o Infoset XML com conteúdo binário que não é apenas aplicável ao pacote SOAP e MIME, mas aplicável a qualquer Infoset XML e qualquer mecanismo de pacote. Por outro lado, o XML não é um bom mecanismo de pacote de uso geral.
Um pacote XOP é criado colocando uma serialização do Infoset XML dentro de um formato de pacote extensível (como o MIME). Observe que o XOP não reutiliza o MIME para o pacote real na ligação. Então, as partes selecionadas de seu conteúdo, que são dados binários codificados por base64, são extraídas e recodificadas, significando que os dados são decodificados de base64 e colocados no pacote. Os locais das partes selecionadas são marcados no XML com um elemento especial que é vinculado aos dados empacotados utilizando URIs.
Os mecanismos de processamento SOAP desempenham uma codificação Base 64 temporária dos dados binários, logo antes da mensagem alcançar a ligação. Essa codificação temporária possibilita que o processador SOAP trabalhe com os dados Base 64, para que, por exemplo, uma WS-Signature dos dados seja obtida e colocada no cabeçalho. Não há necessidade de decodificação dispendiosa na outra extremidade e o processo trabalha em reverso.
As implementações de MTOM e XOP estão disponíveis em (Java™ (JAX-WS).
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo xmlmime:contentType='image/png'>/aWKKapGGyQ=</m:photo>
<m:sig xmlmime:contentType='application/pkcs7-signature'>Faa7vROi2VQ=</m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<mymessage.xml@example.org>";
startinfo="application/soap+xml; action=\"ProcessData\""
Content-Description: Uma mensagem SOAP com my pic e sig
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="application/soap+xml; action=\"ProcessData\""
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>
<soap:Envelope
xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
xmlns:xmlmime='http://www.w3.org/2004/11/xmlmime'>
<soap:Body>
<m:data xmlns:m='http://example.org/stuff'>
<m:photo
xmlmime:contentType='image/png'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/me.png'/></m:photo>
<m:sig
xmlmime:contentType='application/pkcs7-signature'><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://example.org/my.hsh'/></m:sig>
</m:data>
</soap:Body>
</soap:Envelope>
--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>
// octetos binários para png
--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>
// octetos binários para assinatura
--MIME_boundary--