Cxf Content Transfer Koding Binære Alternativer

Håndtering av binære data med Axis2 (MTOMSwA) Innledning Til tross for fleksibilitet, interoperabilitet og global aksept av XML, er det tider når seriellisering av data i XML ikke gir mening. Brukere av webtjenester vil kanskje sende binære vedlegg av ulike typer som bilder, tegninger, XML-dokumenter, etc. sammen med en SOAP-melding. Slike data er ofte i et bestemt binært format. Tradisjonelt har to teknikker blitt brukt til å håndtere ugjennomsiktige data i XML Sende binære data etter verdi oppnås ved å inkludere ugjennomsiktige data (selvfølgelig etter noen form for koding) som et element eller attributt innhold av XML-komponenten av data. Den største fordelen med denne teknikken er at den gir applikasjoner muligheten til å behandle og beskrive data, basert bare på XML-komponenten av dataene. XML støtter ugjennomsiktig data som innhold ved bruk av enten base64 eller hexadecimal tekstkoding. Begge teknikkene oppløser størrelsen på dataene. For UTF-8 underliggende tekstkodning øker base64-kodingen størrelsen på binærdata med en faktor på 1,33x av den opprinnelige størrelsen, mens heksadesimal koding utvider data med en faktor 2x. Ovennevnte faktorer vil bli doblet hvis UTF-16 tekstkoding brukes. Også bekymring er overhead i prosesseringskostnader (både virkelige og oppfattede) for disse formatene, spesielt når dekoderes tilbake til rå binær. Sending av binær data ved referanse oppnås ved å knytte rene binære data til eksterne unparsed generelle enheter utenfor XML-dokumentet, og deretter legge inn referanse-URIer til de enhetene som elementer eller attributtverdier. Dette forhindrer unødvendig oppblåsthet av data og sløsing med prosessorkraft. Det primære hindret for å bruke disse uparbeide enhetene er deres sterke tillit til DTDer, noe som hindrer modularitet samt bruk av XML-navneområder. Det var flere spesifikasjoner som ble introdusert i webtjenestenes verden for å håndtere dette binære vedleggsproblemet ved hjelp av quotby referencequot-teknikken. SOAP med vedlegg er et slikt eksempel. Siden SOAP forbyder dokumenttypedeklarasjoner (DTD) i meldinger, fører dette til problemet med ikke å representere data som en del av meldingsinformasjonen, og oppretter derfor to datamodeller. Dette scenariet er som å sende vedlegg med en e-postmelding. Selv om disse vedleggene er relatert til meldingsinnholdet, er de ikke inne i meldingen. Dette forårsaker teknologiene som behandler og beskriver dataene basert på XML-komponenten av dataene til feil. Et eksempel er WS-Security. Hvor kommer MTOM i MTOM (SOAP Message Transmission Optimization Mechanism) er en annen spesifikasjon som fokuserer på å løse problematikken kvotering. MTOM forsøker å utnytte fordelene ved de to teknikkene ovenfor ved å prøve å slå sammen de to teknikkene. MTOM er faktisk en quotby referencequot metode. Trådformatet til en MTOM optimalisert melding er det samme som SOAP med Vedlegg melding, som også gjør det bakoverkompatibelt med SwA endepunkter. Den mest bemerkelsesverdige funksjonen til MTOM er bruken av XOP: Include-elementet, som er definert i XOP-spesifikasjonen for XML-binæroptimalisering (XOP) for å referere til binære vedlegg (eksterne ikke-sparsomme generelle enheter) av meldingen. Ved bruk av dette eksklusive elementet blir det vedlagte binære innholdet logget inline (etter verdi) med SOAP-dokumentet, selv om det faktisk er festet separat. Dette fusjonerer de to rikene ved å gjøre det mulig å arbeide bare med en datamodell. Dette gjør at programmene kan behandles og beskrives ved bare å se på XML-delen, noe som gjør avhengigheten av DTDs foreldet. På et lettere notat har MTOM standardisert referansemekanismen til SwA. Følgende er et utdrag fra XOP-spesifikasjonen. På begrepsnivå kan disse binære dataene anses å være base64-kodet i XML-dokumentet. Siden dette konseptuelle skjemaet kan være nødvendig under noen behandling av XML-dokumentet (for eksempel for å signere XML-dokumentet), er det nødvendig å ha en en-til-en korrespondanse mellom XML Infosets og XOP Packages. Derfor er den konseptuelle representasjonen av slike binære data som om den var base64-kodet, ved hjelp av den kanoniske leksikalske formen for XML Schema base64Binary datatype (se XML Schema Part 2: Datatypes Second Edition 3.2.16 base64Binary). I motsatt retning er XOP i stand til å optimalisere bare base64-kodet Infoset-data som er i den kanoniske leksikalske formen. Apache Axis2 støtter Base64-koding. SOAP med vedlegg og MTOM (SOAP Message Transmission Optimization Mechanism). MTOM med Axis2 Programmeringsmodell AXIOM er (og kan være den første) Objektmodellen som har muligheten til å holde binære data. Den har denne egenskapen, da OMText kan holde rå binært innhold i form av javax. activation. DataHandler. OMText er valgt for dette formålet med to grunner. En er at XOP (MTOM) er i stand til å optimalisere bare base64-kodet Infoset-data som er i den kanoniske leksikalske formen for XML Schema base64Binary datatype. Den andre er å bevare infosettet i både avsender og mottaker. (For å lagre det binære innholdet i samme type objekt uansett om det er optimalisert eller ikke). MTOM gjør det mulig å selektivt kode inn deler av meldingen, som tillater oss å sende base64enkodede data samt eksternt vedlagte rå binære data referert av quotXOPquot-elementet (optimalisert innhold) som skal sendes i en SOAP-melding. Du kan spesifisere om en OMText-node som inneholder rå binær data eller base64-kodet binær data, er kvalifisert til å bli optimalisert når byggingen av noden eller senere ble bygget. For optimal effektivitet av MTOM, anbefales en bruker å sende mindre binære vedlegg ved hjelp av base64encoding (ikke-optimalisert) og større vedlegg som optimalisert innhold. Dessuten kan en bruker lage en optimaliserbar binær innholdskode ved hjelp av en base64 kodet streng, som inneholder kodet binært innhold, gitt med MIME-typen av den faktiske binære representasjonen. Axis2 bruker javax. activation. DataHandler til å håndtere binære data. Alle de optimaliserte binære innholdsnodene vil bli serialisert som Base64 Strings hvis quotMTOM ikke er aktivert. Du kan også opprette binære innholdsnoder, som ikke vil bli optimalisert uansett. De vil bli serialisert og sendt som Base64 Strings. Aktiverer MTOM-optimalisering på klientsiden i alternativer, sett egenskapen quotenableMTOMquot til True når du sender meldinger. Når denne egenskapen er satt til True, vil enhver SOAP-konvolutt, uansett om den inneholder optimaliserbart innhold eller ikke, bli serialisert som en MTOM-optimalisert MIME-melding. Axis2 serialiserer alle binære innholdsnoder som Base64-kodede strenger, uavhengig av om de er kvalifisert til å bli optimalisert eller ikke hvis egenskapen quotenableMTOMquot er satt til False. hvis konvolutten inneholder elementelementinformasjon av navnet xop: Inkluder (se XML-binær optimalisert emballasje 3. XOP Infosets Constructs). Brukeren trenger ikke å spesifisere noe for at Axis2 skal kunne motta MTOM optimaliserte meldinger. Axis2 vil automatisk identifisere og de-serialisere tilsvarende, når og når en MTOM-melding kommer. Aktiverer MTOM-optimalisering på serversiden The Axis 2-server identifiserer automatisk innkommende MTOM optimaliserte meldinger basert på innholdstypen og de-serialiserer dem tilsvarende. Brukeren kan aktivereMTOM på server siden for utgående meldinger. For å aktivereMTOM globalt for alle tjenester, kan brukerne sette quotenableMTOMquot parameteren til True i Axis2.xml. Når det er satt, blir alle utgående meldinger serialisert og sendt som MTOM-optimaliserte MIME-meldinger. Hvis den ikke er angitt, blir alle binære dataene i binære innholdsnodene serialisert som Base64-kodede strenger. Denne konfigurasjonen kan overstyres i services. xml på grunnlag av per tjeneste og per operasjon. Du må starte serveren på nytt etter å ha satt denne parameteren. Å få tilgang til mottatte binære data (Eksempelkode) Jeg skriver en enkel webserver i python som tillater en bruker å laste opp en fil ved hjelp av multipartform-data. Så vidt jeg kan fortelle, må multipart MIME-data være linjebasert. For eksempel må grensen være i begynnelsen av en linje. Jeg kan ikke finne ut hvordan binær data håndteres i denne forbindelse. Min klient (Firefox) kodes ikke i 7bit ASCII eller noe, det er bare rå binære data som sendes. Deler dataene i linjer på vilkårlige steder Er det en maksimal linjelengde spesifisert for flerpartsdata Jeg har prøvd å se gjennom RFC for multipartformdata, men fant ikke noe. spurte Mar 27 13 kl 16:54 Etter å ha gravd gjennom RFCs, tror jeg at jeg endelig fikk alt rett i hodet mitt. Kroppsdelene (dvs. kroppsinnholdet til en enkelt del i en flerartsbeskjed) trenger bare å være linjebasert ved at grensen på slutten av delen begynner med en CRLF. Men ellers må dataene ikke være linebaserte, og hvis innholdet skjer for å ha linebreaker i det, er det ingen maksimal avstand mellom dem, og de må heller ikke bli rømt i alle fall (vel, med mindre innholdsoverførings - Koding er sitertråd). De 7-bits, 8-biters og binære alternativene for Content-Transfer-Encoding indikerer ikke faktisk at noen koding har blitt gjort på dataene (og derfor må ingen koding bli utelatt), de er bare ment å indikere typen data du kan forvente å se i kroppsdelen. Det jeg virkelig fikk på i mitt dårlig uttrykte spørsmål var hvordan å lesebuffer dataene fra stikkontakten, slik at jeg kunne forsikre meg om at jeg fanget grensen, og uten å måtte ha en vilkårlig stor buffer (f. eks. Hvis det ikke skjedde noen linebryt i innholdet, og så en sluttlinje endte opp med å buffere hele greia). Det jeg endte med å gjøre var å buffre fra stikkontakten med en leselinje med maksimal lengde, slik at bufferen aldri ville være lengre enn den, men vil også være sikker på å avslutte hvis en linebreak ble oppstått. Dette sørget for at når grensen kom (etter en CRLF), ville det være i starten av bufferen. Jeg måtte gjøre litt ekstra monkeying rundt for å sikre at jeg ikke inkluderte den endelige CRLF i selve kroppsinnholdet, fordi ifølge RFC er det nødvendig før grensen, og derfor ikke en del av selve innholdet. besvart apr 5 13 kl 12:02 Prøv å gjennomgå RFC 2045. Vanligvis blir binært innhold konvertert til BASE64 av din søknad og inkludert i multi-delen meldingen ved hjelp av Content-Transfer-Encoding. Base64. Det finnes andre mekanismer for å overføre binære data, men dette er ganske vanlig. Binære data omdannes til oktetter og chunked ut i arbitriske lengderstrenger (avhengig av kodingsvarianten - se BASE64-lenken ovenfor). Den mottakende applikasjonen dekoder den deretter i det opprinnelige binære innholdet. Jeg er ikke en pythonprogrammerer, men jeg ville bli overrasket over at du virkelig måtte kodes noe av dette selv. Jeg mistenker at det er prebuilt python bibliotek funksjoner å gjøre dette for deg. svarte Mar 27 13 kl 17:43 takk, jeg så på en annen RFC som ikke var så informativ. Jeg fant også RFC 2046 som spesifikt definerer flere delte meldinger i seksjon 5. Merk det er litt subtilitet i disse RFC-ene, som gjennom meg av: det står at flerpartsmeddelinger ikke kan ha kodinger annet enn 7-bit, 8-bit og binær (dvs. ikke Base-64). Men det går videre til å si at de enkelte delene i multi-delen kan ha egne innholdskoder, så du er riktig at Base-64 er mulig. ndash brianmearns 28 mar 13 kl 13:20 Ditt svar 2017 Stack Exchange, IncSending Vedlegg med SOAP SOAP-applikasjoner må ofte håndtere mer enn bare enkle meldinger. Lastbelastningen for en SOAP-melding kan ofte inkludere et tekstbehandlings - eller PDF-dokument, bilde eller annen binærfil. Denne artikkelen forklarer hvordan du bruker MOMM (Message Transmission Optimization Mechanism) for å sende og motta disse meldingene. Last ned denne gratis guiden Gratis håndbok: Java App Development i Cloud Software ingeniører nærmer seg utvikling og bedriftsdesign på en helt ny måte, takket være skyen. I denne eksperthåndboken kan du undersøke hvordan dine jevnaldrende bruker skyen for å effektivisere levetiden for app-livscyklus, spare penger og gjøre produksjon og sikkerhet mer effektiv. Ved å sende inn dine personlige opplysninger, godtar du at TechTarget og dets partnere kan kontakte deg angående relevant innhold, produkter og spesialtilbud. Du samtykker også i at dine personlige opplysninger kan overføres og behandles i USA, og at du har lest og godkjent vilkårene for bruk og personvernreglene. Forutsetninger Denne artikkelen bruker WSO2 Web Services Application Server (WSAS.) Det anbefales at du laster ned og installerer WSO2 WSAS 2.0. Artikkelen bruker servlet-utgaven installert på Apache Tomcat. Enhver applikasjonsserver kan brukes med servlet-versjonen, følg bare installasjonsinstruksjonene som følger med WSO2 WSAS. Du trenger ikke å bruke en applikasjonsserver i det hele tatt, da WSO2 WSAS fungerer bra i et frittstående format. WSO2 WSAS krever Java 1.4 eller 1.5, men det er ingen andre forutsetninger for det. Selvfølgelig er webtjenester og SOAP spesielt brukt, så kjennskap til det vil hjelpe. Når XML ikke er nok: binære data Det finnes endeløse måter å sende data over nettverket. Det finnes mange protokoller og dataformater. Standardisering rundt SOAP har tatt bort mye gjetning i å sende data mellom systemer. SOAP standardiserer protokollen (HTTP) og dataformatet (XML.) En av hovedkritikken til SOAP er bruken av XML. XML er tekstbasert. Dette gjør ikke bare store meldinger, men gjør det uforenlig med binære data. For eksempel, si at meldingen din må inkludere et bilde. Dette gir et problem når meldingsformatet er tekst. Kombinere binære data med SOAP Ok, så du må sende binære data mellom programmer. Du vil gjerne bruke SOAP, men det er begrenset til tekst. Så skal du bare gi opp SOAP alt sammen Selvfølgelig ikke, det er for mange fordeler med SOAP. Du trenger bare en måte å kombinere den med binære data. Du ser nettsider gjør dette hele tiden, det kan ikke være så vanskelig, rett. Lets utforske noen løsninger på dette problemet. En måte du kan prøve er å bare dumpe binæret inn i en tekstknute. Det kan se ut som å lytte 1. Oppføring 1. XML med binære data: Første forsøk Husk at tegn også er byte, akkurat som binære data. En XML-parser, enten det er en DOM-, SAX - eller StAX-parser, må bruke tegnsettkodingen for dokumentet for å tolke alle bytes i dokumentet som tegn. Så våre binære data kan enkelt ha tegn som tilsvarer reservert XML-tegn, som lt eller gt eller forsterker. Enhver slik bytesekvens i tekstknutepunktet ovenfor vil føre til at parseren på den andre siden bryter. Så denne tilnærmingen vil ikke fungere. Men vent, kanskje det er en måte å fikse denne tilnærmingen på. Hva med å bruke en CDATA-blokk som vil fortelle parseren å ignorere tegnene i blokken. Denne modifiserte tilnærmingen kan se ut som Oppføring 2. Oppføring 2. XML med binær: Bruke CDATA Nå, hvis vi har byte som tolkes som gt (for eksempel), vil de bli ignorert. Parseren må imidlertid finne ut hvor CDATA-delen slutter. Det gjør dette ved å lete etter bytesekvensen som svarer til tegnene gt. Det kan virke usannsynlig, men våre binære data kan bare ha en slik bytesekvens i midten av den. Det ville få noen parser til å tro at CDATA-delen var avsluttet, og de etterfølgende tegnene skulle tolkes akkurat som i vårt første forsøk. Så det kommer heller ikke til å fungere. Vi trenger en måte å sikre at disse bytesene ikke tolkes i det hele tatt. Base 64-koding: Fungerer, men oppblåst Det er en løsning på denne varianten av vårt problem. En vanlig måte å gjøre dette på er å bruke Base 64-koding. Denne teknikken har eksistert (som standard) siden 80-tallet. Det innebærer å bruke et 64 tegn alfabet som består av små bokstaver, a-z, store bokstaver, A-Z, tallene 0-9, og symbolene. Hver byte blir kartlagt til disse tegnene, så det er ingen måte for noen byte å bli misfortolket som noe som ville kvele en XML-parser. Så det, problem løst, riktig Ja, men det er en heller ineffektiv løsning. Basen 64 kodede binære vindninger blir i gjennomsnitt 37 større (antall byte) enn de rå, ikke-kodede binære dataene. I tillegg må parseren på den andre siden vite om kodingen slik at den kan dekode nyttelasten. Man kan forestille seg at hvis Base 64-koding var en del av SOAP-standarden, ville det være noen standard måte å indikere denne SOAP-meldingsprosessoren på. Dette er ikke tilfelle, skjønt. Det kan være en løsning, men det er både ineffektivt og ikke-standard. Vi trenger noe som er både mer effektivt og standardisert. SOAP med vedlegg: Fungerer men feil design En løsning på problemet er å bruke det som kalles SOAP med Vedlegg. Ideen her er å bare sette binære data utenfor SOAP-meldingen helt. Figur 1 gir en fin visualisering av dette. Figur 1. SOAP med vedlegg Dette ligner veldig på hvordan binære filer kan festes til e-post. SOAP-meldingen inneholder en referanse til binærfilen som er knyttet til meldingen. Dette er både mer effektivt og standardisert, men det har noen feil i designen. Det binære vedlegget er ikke en del av SOAP-meldingen i det hele tatt. Det ligner på mange måter å bare sende en URI for binær data og la den stå opp til meldingsprosessoren for å hente den faktiske binære data. Den presenterer noen virkelige problemer for ting som WS-Security. Likevel er dette det som ble brukt for en stund, til en bedre løsning ble foreslått: MTOM. MTOM: Best of both worlds MTOM står for SOAP Message Transmission Optimization Mechanism. Den kombinerer effektiviteten til SOAP med vedlegg, men det gjør det uten å bryte binære data utenfor SOAP-meldingen. Hvordan kan dette være Nøkkelen er en teknologi som heter XML-binær optimalisert emballasje eller XOP. XOP gjør det mulig å inkludere binære data som en del av XML Infoset. Faktisk blir XML Infoset en superset av det tradisjonelle Infoset kjent som XOP Infoset. Det tillater at binære data lagres utenfor XML-dokumentet, akkurat som i SOAP med vedlegg. Den bruker en spesiell XOP: Inkluder element for å fortelle prosessoren å erstatte innholdet med refererte binære data, og dermed inkapslere logikken for diskret lagring og gjenfinning av binære data. Denne logikken blir iboende av XML-parseren, og tillater SOAP-parseren å behandle binære data som en del av XML-dokumentet, uten spesiell gjenfinningslogikk. På samme måte tillater det en SOAP-server å lage en SOAP-melding på en ensartet måte, ingen spesiell logikk for å bryte ut den binære data fra SOAP-meldingen. MTOM i WSO2 WSAS Weve snakket mye om behovet for MTOM og hvordan det skal fungere i teorien. Det gjør oss ikke så bra uten en virkelig implementering. Heldigvis er det en enkel måte å få en flott MTOM-implementering på, bare bruk WSO2 WSAS. WSO2 WSAS er bygget på grunnlag av prøvde og sanne teknologier, inkludert Apache Axis2. Axis2 gir WSO2 WSAS sin MTOM implementering. La oss ta en titt på hvordan du kan tappe inn i kraften til WSASAxis2s MTOM-implementering. Sende en MTOM-melding fra en webtjeneste med Axiom API MTOM-støtten på Axis2 bygger på de samme klassene som brukes i hele Axis2. Den bruker Axis2s Object Model (OM). Axis2 støtter både Base 64-koding og MTOM, og gjør det relativt enkelt å bytte mellom dem. Hvorfor Vel for svært små filer, kan det faktisk være mer effektivt å bruke Base 64-koding. For å oppnå denne sømløse bytte mellom optimalisert og ikke-optimalisert transport, behandler Axis2 binære data som en XML-tekstknutepunkt. Den eneste forskjellen er at du må passere i en javax. activation. DataHandler for å få tilgang til dataene, som vist i Listing 3. Listing 3. Legge til binære data med Axiom API I eksemplet i liste 3, en javax. activation. FileDataSource brukes til å gi DataHandler tilgang til binære data. Du kan bruke hvilken som helst klasse som implementerer javax. activation. DataSource-grensesnittet. For eksempel, når du arbeider med bilder, kan org. apache. axis2.attachments. ImageDataSource brukes. Den implementerer DataSource-grensesnittet og kan være mer praktisk når du arbeider med bilder. Så hvordan kan Axis2, og dermed WSO2 WSAS, vite å bruke MTOM for å optimalisere binære data? Det er faktisk hva Axis2 vil gjøre som standard. Du kan manuelt overstyre dette ved å legge til bare én linje med kode, som vist i Oppføring 4. Oppføring 4. Slå av MTOM Den ene linjen med kode vil fortelle at Axis2 ikke skal optimaliseres, det vil si ikke bruk MTOM. Dermed vil Axis2 bruke Base 64-koding av binære data, og det vil virkelig være en tekstknute. Ellers vil MTOM sparke inn, og en XOP-inkludering vil bli brukt til å optimalisere transporten av binære data i SOAP-meldingen. Aktiverer MTOM på serveren Selvfølgelig for å få all denne fantastiske, automatisk optimaliserte oppføringen, trenger du å aktivere MTOM. Du kan gjøre dette gjennom din aksel2.xml-fil veldig enkelt som vist i Oppføring 5. Oppføring 5. Aktivering av MTOM i axis. xml Det kan ikke bli mer smertefritt enn det, rett Dette er en global innstilling, og er standardinnstillingen på WSO2 wsas. Du kan faktisk aktivere MTOM på fire forskjellige nivåer: global, tjenestegruppe, service og drift. Du bruker samme semantikk for hvert nivå. Du kan bruke Administrasjonskonsollen til å administrere MTOM på hvert av disse nivåene. Se for eksempel på figur 2. Figur 2. Administrere MTOM på servicegruppenivå Her ser vi at MTOM blir administrert på servicegruppenivå. Hver tjeneste i gruppen kan også administreres individuelt, som vist på figur 3. Figur 3. Administrere MTOM på servicenivå Selvfølgelig kan hver tjeneste ha en eller flere operasjoner. WSAS lar deg styre MTOM på det nivået, som vist i figur 4. Legg merke til at på hvert nivå har MTOM tre mulige verdier: sann, falsk og valgfri. Hvis eiendommen er satt til sann, vil tjenesten sende en optimalisert melding når det er nødvendig, dvs. når binære data er inkludert. Hvis verdien er satt til feil, vil optimalisering aldri bli brukt, og Base 64-koding vil bli brukt for alle binære data. Hvis det er satt til valgfritt, vil WSAS optimalisere hvis og bare hvis forespørselen kom inn, ble optimalisert. Typen av forespørsel vil indikere til WSAS hvis den skulle bruke MTOM eller ikke. Hvorfor trenger vi denne typen fleksibilitet Som nevnt tidligere er det ofte fordelaktig å bruke Base 64-koding på små filer. Dermed kan du bestemme at visse operasjoner skal bruke MTOM, og andre bør ikke. Eller du kan gjøre det valgfritt ved en operasjon, gjør en kontroll for størrelsen på dataene som sendes, og velg deretter å overstyre standard MTOM hvis filen er liten. Så sender du MTOM. La oss se på hvor enkelt WSAS gjør det til å sende en MTOM-melding fra en webtjenerklient. Opprette en SOAP-klient som sender MTOM-meldinger Det er like enkelt å sende en MTOM-melding fra en klient som å sende en MTOM-melding fra en webtjeneste. Axis2 gir flere praktiske APIer. Et eksempel er vist i Listing 6. Listing 6. Klientkode for sending av MTOM melding Som du kan se i Listing 6, er det viktig å gjøre det mulig å aktivere MTOM i alternativer for webtjenerklienten. Når du gjør det, vil Axis2 optimalisere alle binære data du sender til webtjenesten ved hjelp av MTOM automatisk. Vi har sett hvordan du sender MTOM-meldinger fra en webtjeneste og til en webtjeneste, nå kan vi se hvordan vi kan jobbe med data som er sendt via MTOM. Håndtere en MTOM-melding i en webtjeneste Nå kan vi anta at du har en webtjeneste som aksepterer binære data som en del av en SOAP-melding fra en klient. Hvis webtjenesten din kjører på WSAS, trenger du ikke å gjøre noe spesielt for å kunne håndtere optimaliserte binære data fra kundene dine. Dine kunder kan sende SOAP-meldinger som bruker MTOM eller Base 64-koding. Det er alt sømløst med WSAS. Oppføring 7 viser et eksempel på mottak av optimalisert data. Oppføring 7. Web service mottak optimalisert SOAP Som vi så tidligere behandler Axiom API den binære data som en tekstknute. Dette tillater en enkelt API for å håndtere optimalisert og ikke-optimalisert (Base 64-kodet) data. Du får bare tilgang til DataHandler tilknyttet tekstnoden (som inneholder binær data) og bruker det for å skaffe en InputStream. Når du har InputStream, kan du lese alle bytes og behandle dem, men du trenger det. WSAS gjør det enkelt å håndtere SOAP-meldinger med optimaliserte binære data nyttelast. La oss se på hvor enkelt det er å jobbe med MTOM på klienter. Håndtere en MTOM-melding i en klient Det er ingen magi for å håndtere et MTOM-webservicesvar. Weve har allerede sett hvordan du konfigurerer forespørselen. I figur 8 ser du hvordan du skal håndtere et svar som inneholder binær data optimalisert med MTOM. Igjen nøkkelen her bruker Axiom API. Det lar oss behandle binære data som en tekstknute, og deretter bruke DataHandler til å få en InputStream til dataene. Igjen, når du har InputStream, kan du behandle dataene du trenger. Weve sett hvordan MTOM gir den perfekte kombinasjonen av SOAP-standardisering og effektivitet for transport av binære data i en webtjenestemelding. Weve sett hvordan WSO2 WSAS implementerer MTOM-spesifikasjonen ved hjelp av Axis2. Vi har tatt en titt på hvordan du konfigurerer både webserverservere og klienter til både å sende og motta MTOM optimaliserte meldinger. Nå har vi alt vi trenger for å legge til binære data i våre webtjenester ved hjelp av WSO2 WSAS. Du kommer til å ønske å laste ned WSO2 WSAS. Les om de nyeste funksjonene i WSO2 WSAS 2.0. Lær av og samhandle med WSO2-fellesskapet på WSAS Wiki. Lær om å eksponere dine tjenester som webtjenester enkelt med Axis2. Lær hvordan Axis2 kan aktivere SOA-designene i developerWorks-artikkelen SOA med Axis2. Lær alt om Axis interoperabilitet med andre webtjenester implementeringer i denne oppføringen i TSS Interoperability bloggen. Dykk inn i AXIOM API i developerWorks-artikkelen Få mest mulig ut av XML-behandling med AXIOM. Les alt om XOP og MTOM i denne blogginnlegget av Mark Nottingham. Interoperabilitet er navnet på spillet når det gjelder webtjeneste, så lære om å bruke MTOM med i artikkelen Sende filer i biter med MTOM Web Services og 2.0. Om forfatteren Michael Galpin er en arkitekt på eBay i San Jose, CA. Han har utviklet programvare siden 1998, og har en grad i matematikk fra California Institute of Technology.