Hantering av binär data med Axis2 (MTOMSwA) Inledning Trots flexibilitet, interoperabilitet och global acceptans av XML finns det tillfällen då serialisering av data i XML inte är meningsfullt. Användare av webbtjänster kan vilja skicka binära bilagor av olika slag som bilder, ritningar, XML-dokument etc. tillsammans med ett SOAP-meddelande. Sådan data är ofta i ett visst binärt format. Traditionellt har två tekniker använts för att hantera opaka data i XML Sändning av binär data efter att värdet uppnås genom att bädda in ogenomskinliga data (naturligtvis efter någon form av kodning) som ett element eller attributinnehåll i XML-komponenten av data. Den största fördelen med denna teknik är att den ger applikationer möjlighet att bearbeta och beskriva data, baserade endast på XML-komponenten i data. XML stöder opaka data som innehåll genom användning av antingen base64 eller hexadecimal textkodning. Båda teknikerna uppblåser dataens storlek. För UTF-8 underliggande textkodning ökar bas64-kodningen storleken på binärdata med en faktor 1,33x av originalstorleken, medan hexadecimal kodning expanderar data med en faktor 2x. Ovanstående faktorer kommer att fördubblas om UTF-16-textkodning används. Också oroa är överkostnaden i bearbetningskostnader (både verkliga och uppfattade) för dessa format, särskilt när de avkodas tillbaka till rå binär. Sändning av binär data genom referens uppnås genom att bifoga ren binär data som externa icke-uppdelade generella enheter utanför XML-dokumentet och sedan inbädda referens-URI till dessa enheter som element eller attributvärden. Detta förhindrar onödig uppblåstning av data och slöseri med bearbetningseffekt. Det primära hindret för att använda dessa oförsäkrade enheter är deras starka beroende av DTD, vilket hindrar moduläritet samt användningen av XML-namnområden. Det fanns flera specifikationer införda i webbtjänsten världen för att hantera detta binära bilagan problem med quotbot referencequot teknik. SOAP med bilagor är ett sådant exempel. Eftersom SOAP förbjuder dokumenttypdeklarationer (DTD) i meddelanden leder det till problemet att inte representera data som en del av meddelandet infoset, vilket därför skapar två datamodeller. Det här scenariot är som att skicka bilagor med ett e-postmeddelande. Även om dessa bilagor är relaterade till meddelandeinnehållet är de inte inuti meddelandet. Detta medför att teknologier som behandlar och beskriver data som baseras på XML-komponenten i dataen till funktionsfel. Ett exempel är WS-Security. Var kommer MTOM i MTOM (SOAP Message Transmission Optimization Mechanism) att vara en annan specifikation som fokuserar på att lösa problematiket quotAttachmentsquot. MTOM försöker utnyttja fördelarna med ovanstående två tekniker genom att försöka slå samman de två teknikerna. MTOM är faktiskt en kvotisk referensvärdesmetod. Trådformatet för ett MTOM-optimerat meddelande är detsamma som meddelandet SOAP med bilagor, vilket också gör det bakåtkompatibelt med SwA-ändpunkter. Den mest anmärkningsvärda egenskapen hos MTOM är användningen av XOP: Include-elementet, som definieras i XML-binär optimerad förpackning (XOP) - specifikation för att referera till binära bilagor (externa icke-sammanslagna generella enheter) av meddelandet. Med hjälp av detta exklusiva element blir det bifogade binära innehållet logiskt inline (enligt värde) med SOAP-dokumentet, även om det faktiskt är fäst separat. Detta sammanfogar de två världarna genom att göra det möjligt att bara arbeta med en datamodell. Detta gör att applikationerna kan behandlas och beskrivas genom att bara titta på XML-delen, vilket gör förlitningen på DTD-föråldrade. På en lättare not har MTOM standardiserat referensmekanismen för SwA. Följande är ett utdrag ur XOP-specifikationen. På konceptuell nivå kan denna binära data anses vara bas64-kodad i XML-dokumentet. Eftersom denna konceptuella form kan behövas under viss behandling av XML-dokumentet (till exempel för att signera XML-dokumentet) är det nödvändigt att ha en en-till-en-korrespondens mellan XML Infosets och XOP Packages. Därför är den konceptuella representationen av sådan binär data som om den var bas64kodad, med hjälp av den kanoniska lexikala formen av XML Schema base64Binary datatype (se XML Schema Del 2: Datatyper Second Edition 3.2.16 base64Binary). I omvänd riktning kan XOP optimera endast base64-kodade Infoset-data som finns i den kanoniska lexiska formen. Apache Axis2 stöder Base64-kodning. SOAP med bilagor och MTOM (SOAP Message Transmission Optimization Mechanism). MTOM med Axis2 Programmeringsmodell AXIOM är (och kan vara den första) objektmodellen som har förmågan att hålla binär data. Den har denna förmåga eftersom OMText kan hålla rå binärt innehåll i form av javax. activation. DataHandler. OMText har valts ut för detta ändamål av två skäl. En är att XOP (MTOM) kan optimera endast base64-kodade Infoset-data som finns i den kanoniska lexiska formen av XML Schema base64Binary datatype. Den andra är att bevara infosetet både i avsändaren och mottagaren. (För att lagra binärinnehållet i samma typ av objekt oavsett om det är optimerat eller inte). MTOM tillåter att koda delar av meddelandet selektivt, vilket tillåter oss att skicka base64enkodad data såväl som externt bifogad rå binär data refererad av quotXOPquot-elementet (optimerat innehåll) som ska skickas i ett SOAP-meddelande. Du kan ange om en OMText-nod som innehåller rå binär data eller base64enkodad binär data är kvalificerad att optimeras vid konstruktion av den noden eller senare. För optimal effektivitet av MTOM rekommenderas en användare att skicka mindre binära bilagor med hjälp av base64encoding (nonoptimerade) och större bilagor som optimerat innehåll. Dessutom kan en användare skapa en optimerbar binär innehållsnod med en bas64 kodad sträng, som innehåller kodat binärt innehåll, som ges med MIME-typen för den faktiska binära representationen. Axis2 använder javax. activation. DataHandler för att hantera binär data. Alla optimerade binära innehållsnoder kommer serialiseras som Base64-strängar om quotMTOM inte är aktiverat. Du kan också skapa binära innehållsnoder, som inte optimeras under alla omständigheter. De kommer att serialiseras och skickas som Base64-strängar. Aktivera MTOM-optimering på klientsidan I alternativ, ställ in egenskapen quotenableMTOMquot till True när du skickar meddelanden. När den här egenskapen är satt till True, kommer ett SOAP-kuvert, oberoende av om det innehåller optimerbart innehåll eller inte, serialiseras som ett MTOM-optimerat MIME-meddelande. Axis2 serialiserar alla binära innehållsnoder som Base64-kodade strängar oavsett om de är kvalificerade att optimeras eller inte om egenskapen quotenableMTOMquot är inställd på False. om kuvertet innehåller elementelementinformation av namnet xop: Inkludera (se XML-binär optimerad förpackning 3. XOP Infosets Constructs). Användaren behöver inte ange något för att Axis2 ska kunna få MTOM optimerade meddelanden. Axis2 identifierar och aviserar automatiskt efter varandra, när och när ett MTOM-meddelande kommer fram. Aktivera MTOM-optimering på serverns sida Axis 2-servern identifierar automatiskt inkommande MTOM-optimerade meddelanden baserat på innehållstypen och serialiserar dem därefter. Användaren kan aktiveraMTOM på serverns sida för utgående meddelanden. Om du vill aktiveraMTOM globalt för alla tjänster kan användare ställa in quotenableMTOMquot-parametern till True i Axis2.xml. När det är inställt kommer alla utgående meddelanden att serialiseras och skickas som MTOM-optimerade MIME-meddelanden. Om den inte är inställd kommer alla binära data i binära innehållsnoderna att serialiseras som Base64-kodade strängar. Denna konfiguration kan överskridas i services. xml på basis av per tjänst och per operation. Du måste starta om servern efter att ha ställt in denna parameter. Åtkomst till mottagen binär data (provkod) Jag skriver en enkel webbserver i python som tillåter en användare att ladda upp en fil med multipartformdata. Såvitt jag kan säga, ska multipart MIME-data vara linjebaserad. Till exempel måste gränsen vara i början av en linje. Jag kan inte räkna ut hur binär data hanteras i detta avseende. Min klient (Firefox) kodar inte den i 7bit ASCII eller något, det är bara rå binär data som den skickar. Delar den data i rader på godtyckliga platser Finns det en maxlinjelängd som anges för multipartdata Ive försökte titta igenom RFC för multipartformdata, men hittade inte någonting. frågade mar 27 13 klockan 16:54 Efter att ha grävt igenom RFC: erna tror jag att jag äntligen fick allt rakt i mitt huvud. Kroppsdelarna (dvs kroppsinnehållet i en enskild del i ett multipartmeddelande) behöver bara vara linjebaserade, eftersom gränsen vid delens ände börjar med en CRLF. Men annars behöver inte data vara linjebaserade, och om innehållet råkar ha linebreaker i det, finns det ingen maximal avstånd mellan dem, och de behöver inte heller bli undanflyttade i alla fall (såvida inte innehållet-överföring - Kodning är citerad-sträng). De 7-bitars, 8-bitars och binära alternativen för Content-Transfer-Encoding indikerar inte faktiskt att någon kodning har gjorts på data (och därför behöver ingen kodning ångras), de betyder bara att indikera typen av data du kan förvänta dig att se i kroppsdelen. Vad jag verkligen kom fram i min dåligt uttryckta fråga var hur man läserbufferten data från uttaget så att jag kunde se till att jag fångade gränsen och utan att behöva ha en godtycklig stor buffert (till exempel om det inte hänt några linjebrytningar i innehållet, och så en läsning slutade buffra hela saken). Vad jag slutade göra var att buffra från uttaget med en läsning med en maximal längd, så bufferten skulle aldrig vara längre än den, men skulle också se till att avsluta om en linebreak uppstod. Detta säkerställde att när gränsen kom (efter en CRLF) skulle den vara i början av bufferten. Jag var tvungen att göra lite extra monkeying runt för att försäkra att jag inte inkluderade den slutliga gränsvärdet för den faktiska kroppens innehåll, eftersom enligt RFC krävs det innan gränsen, och därför inte en del av innehållet i sig. svarat den 5 april kl 12:02 Försök att granska RFC 2045. Vanligtvis omvandlas binärt innehåll till BASE64 av din ansökan och ingår i multibildmeddelandet med Content-Transfer-Encoding. Base64. Det finns andra mekanismer för att överföra binär data, men det är ganska vanligt. Binära data omvandlas till oktetter och klickas ut i strängar med arvslängder (beroende på kodningsvarianten - se BASE64-länken ovan). Den mottagande applikationen avkodar sedan den i den ursprungliga binära innehållet. Jag är inte en pythonprogrammerare, men jag skulle bli förvånad över att du verkligen måste koda något av detta själv. Jag misstänker att det finns förbyggda python biblioteksfunktioner att göra det här för dig. svarat mar 27 13 klockan 17:43 Tack, jag tittade på en annan RFC som inte var så informativ. Jag hittade också RFC 2046 som specifikt definierar flera delade meddelanden i avsnitt 5. Notera att det är lite subtilitet i dessa RFC: er som genom mig: det står att multipartmeddelanden inte kan ha kodningar annat än 7-bitars, 8-bitars och binära (dvs inte bas-64). Men det går vidare att säga att de enskilda delarna inom flera delar kan ha egna innehållskodningar, så du är korrekt att Base-64 är möjlig. ndash brianmearns 28 mar 13 kl 13:20 Ditt svar 2017 Stack Exchange, IncSending Attachments med SOAP SOAP-applikationer måste ofta hantera mer än bara enkla meddelanden. Återlösen för ett SOAP-meddelande kan ofta innehålla ett ordbehandlings - eller PDF-dokument, en bild eller en annan binär fil. I den här artikeln beskrivs hur du använder MTOM för att skicka och ta emot dessa meddelanden. Ladda ner den här fria guiden Gratis handbok: Java App Development i Cloud Software Engineers närmar sig utveckling och företagsdesign på ett helt nytt sätt tack vare molnet. I den här experthandboken kan du undersöka hur dina kollegor utnyttjar molnet för att effektivisera appens livscykelhantering, spara pengar och göra produktion och säkerhet effektivare. Genom att lämna in din personliga information, godkänner du att TechTarget och dess partners kan kontakta dig angående relevant innehåll, produkter och specialerbjudanden. Du godkänner också att din personliga information kan överföras och behandlas i USA, och att du har läst och godkänt användarvillkoren och sekretesspolicyen. Förutsättningar Denna artikel använder WSO2 Web Services Application Server (WSAS.) Det rekommenderas att du hämtar och installerar WSO2 WSAS 2.0. Artikeln använder servletupplagan installerad på Apache Tomcat. Alla applikationsservern kan användas med servletversionen, följ bara installationsanvisningarna som ingår i WSO2 WSAS. Du behöver inte använda en applikationsserver alls, eftersom WSO2 WSAS fungerar bra i ett fristående format. WSO2 WSAS kräver Java 1.4 eller 1.5 men det finns inga andra förutsättningar för det. Naturligtvis används webbtjänster och SOAP speciellt, så förtrogenhet med det kommer att hjälpa till. När XML inte räcker: binär data Det finns oändliga sätt att skicka data över nätverket. Det finns många protokoll och dataformat. Standardisering kring SOAP har tagit bort mycket gissningen i att skicka data mellan system. SOAP standardiserar protokollet (HTTP) och dataformatet (XML.) En av huvudkritikerna av SOAP är dess användning av XML. XML är textbaserad. Detta gör inte bara stora meddelanden, men gör det oförenligt med binära data. Låt oss till exempel säga att ditt meddelande måste inkludera en bild. Detta innebär ett problem när ditt meddelandeformat är text. Kombinera binär data med SOAP Ok, så du måste skicka binär data mellan program. Du gillar att använda SOAP, men det är begränsat till text. Så ska du bara ge upp SOAP alla tillsammans Naturligtvis inte, det finns för många fördelar med SOAP. Du behöver bara ett sätt att kombinera det med binär data. Du ser att webbsidor gör det hela tiden det kan inte vara så svårt, rätt. Låt oss utforska några lösningar på det här problemet. Ett sätt du kan försöka är att helt enkelt dumpa binären i en textnod. Det kan se ut som Listing 1. Listing 1. XML med binär data: Först försök Kom ihåg att tecken också är byte, precis som binära data. En XML-parser, oavsett om det är en DOM-, SAX - eller StAX-parser, måste använda teckensekvenskodningen för dokumentet för att tolka alla bitar i dokumentet som tecken. Så vår binära data kan enkelt ha tecken som motsvarar reserverade XML-tecken, som lt eller gt eller amp. Varje sådan bytesekvens i textnod ovan kommer att leda till att parsern på den andra sidan bryts. Så detta tillvägagångssätt kommer inte att fungera. Men vänta, kanske det är ett sätt att åtgärda detta tillvägagångssätt. Vad sägs om att använda ett CDATA-block som kommer att berätta för parsern att ignorera tecknen i blocket. Detta modifierade tillvägagångssätt kan se ut som Listning 2. Listing 2. XML with Binary: Använda CDATA Nu om vi har byte som skulle tolkas som en gt (till exempel) kommer de att ignoreras. Parsern måste emellertid avgöra var CDATA-sektionen slutar. Det gör det genom att leta efter bytesekvensen som motsvarar tecknen gt. Det kan tyckas osannolikt, men vår binära data kan bara ha en sådan bytesekvens i mitten av den. Det skulle få någon parsare att tro att CDATA-sektionen hade slutat och de efterföljande tecknen skulle tolkas precis som i vårt första försök. Så det kommer inte heller att fungera. Vi behöver ett sätt att se till att dessa byte inte tolkas alls. Bas 64 kodning: Fungerar men uppblåst Det finns en lösning på denna variant av vårt problem. Ett vanligt sätt att göra detta är att använda Base 64-kodning. Denna teknik har funnits (som standard) sedan 80-talet. Det handlar om att använda ett 64 tecken alfabet som består av små bokstäver, a-z, versaler, A-Z, siffrorna 0-9 och symbolerna. Varje byte får kartläggas till dessa tecken, så det finns inget sätt för någon byte att bli felintolkad som någonting som skulle kväva en XML-parser. Så där, problem löst, rätt Ja, men det är en ganska ineffektiv lösning. Bas 64-kodade binära vindar är i genomsnitt 37 större (antal byte) än den råa, icke-kodade binära data. Dessutom behöver parsern på andra sidan veta om kodningen så att den kan avkoda nyttolastet. Man kan tänka sig att om Base 64-kodning var en del av SOAP-standarden, skulle det finnas ett vanligt sätt att indikera dessa SOAP-meddelandeprocessorer. Detta är emellertid inte fallet. Det kan vara en lösning, men det är både ineffektivt och icke-standard. Vi behöver något som är både mer effektivt och standardiserat. SOAP med bilagor: Fungerar men bristfällig design En lösning på problemet är att använda det så kallade SOAP med Attachments. Tanken här är att bara sätta binärdata utanför SOAP-meddelandet helt. Figur 1 ger en fin visualisering av detta. Figur 1. SOAP med bilagor Detta liknar mycket hur binära filer kan fästas på e-postmeddelanden. SOAP-meddelandet innehåller en hänvisning till binärfilen som är kopplad till meddelandet. Detta är både mer effektivt och standardiserat, men det har vissa brister i sin design. Den binära bilagan är inte en del av SOAP-meddelandet alls. Det liknar på många sätt att bara överföra en URI för binär data och lämna den upp till meddelandeprocessorn för att hämta den faktiska binära data. Det presenterar några verkliga problem för saker som WS-Security. Ändå är detta det som användes ett tag tills en bättre lösning föreslogs: MTOM. MTOM: Bäst av båda världar MTOM står för SOAP Message Transmission Optimization Mechanism. Det kombinerar effektiviteten av SOAP med bilagor, men det gör det utan att behöva bryta binärdata utanför SOAP-meddelandet. Hur kan detta vara Nyckeln är en teknik som heter XML-binär Optimerad Packaging eller XOP. XOP tillåter binär data att inkluderas som en del av XML Infoset. I själva verket blir XML Infoset en superset av den traditionella Infoset känd som XOP Infoset. Det tillåter att binär data lagras utanför XML-dokumentet, precis som i SOAP med bilagor. Den använder ett speciellt XOP: inkludera element för att berätta för processorn att ersätta innehållet med den refererade binära data, vilket därigenom inkapslar logiken för diskret lagring och hämtning av binärdata. Denna logik blir inneboende för XML-parsern och tillåter SOAP-parsern att behandla binärdata som en del av XML-dokumentet, utan någon särskild retrievallogik. På samma sätt gör det möjligt för en SOAP-server att skapa ett SOAP-meddelande på ett enhetligt sätt, ingen särskild logik för att bryta ut den binära data från SOAP-meddelandet. MTOM i WSO2 WSAS Weve pratade mycket om behovet av MTOM och hur det ska fungera i teorin. Det gör oss inte mycket bra utan en riktig implementering. Lyckligtvis är det ett enkelt sätt att få en bra MTOM-implementering, använd bara WSO2 WSAS. WSO2 WSAS bygger utöver försökt och sant teknik, inklusive Apache Axis2. Axis2 ger WSO2 WSAS sin MTOM-implementering. Låt oss se hur vi kan utnyttja kraften i WSASAxis2s MTOM-implementering. Skicka ett MTOM-meddelande från en webbtjänst med Axiom API MTOM-stöd på Axis2 bygger på samma klasser som används i Axis2. Den använder Axis2s Object Model (OM). Axis2 stöder både Base 64-kodning och MTOM, och gör det relativt enkelt att växla mellan dem. Varför Tja, för mycket små filer, kan det faktiskt vara effektivare att använda Base 64-kodning. För att uppnå denna sömlösa växling mellan optimerad och ickeoptimerad transport behandlar Axis2 binär data som en XML-textnod. Den enda skillnaden är att du måste skicka i en javax. activation. DataHandler för åtkomst till data, som visas i Listing 3. Listing 3. Lägga till binära data med Axiom API I exemplet i Listing 3, en javax. activation. FileDataSource används för att ge DataHandler tillgång till binär data. Du kan använda vilken klass som helst som implementerar gränssnittet javax. activation. DataSource. När du till exempel arbetar med bilder kan org. apache. axis2.attachments. ImageDataSource användas. Det implementerar DataSource-gränssnittet och kan vara bekvämare när du arbetar med bilder. Så hur vet Axis2 och därmed WSO2 WSAS att använda MTOM för att optimera binärdata? Det är faktiskt vad Axis2 ska göra som standard. Du kan manuellt åsidosätta detta genom att lägga till en enda kod, som visas i Listing 4. Listing 4. Slå av MTOM Den enda raden av kod kommer att berätta för Axis2 att inte optimera, dvs använd inte MTOM. Således kommer Axis2 att använda bas 64-kodning av binärdata, och det kommer verkligen att bli en textnod. Annars kommer MTOM att sparka in, och en XOP-inkludering kommer att användas för att optimera transporten av binärdata inom SOAP-meddelandet. Aktivera MTOM på servern Naturligtvis för att få allt detta underbara, automatiskt optimerade beteende, behöver du aktivera MTOM. Du kan göra detta via din axel2.xml-fil mycket enkelt, som visas i Listning 5. Listning 5. Aktiverar MTOM i axel. xml Det kan inte bli mer smärtfritt än det, rätt Det här är en global inställning och är standardinställningen på WSO2 WSAS. Du kan faktiskt aktivera MTOM på fyra olika nivåer: global, servicegrupp, service och drift. Du använder samma semantik för varje nivå. Du kan använda Management Console för att hantera MTOM på var och en av dessa nivåer. Se till exempel på Figur 2. Figur 2. Hantera MTOM på servicegruppenivå Här ser vi att MTOM hanteras på servicegruppenivå. Varje tjänst i gruppen kan också hanteras individuellt, som visas i Figur 3. Figur 3. Hantera MTOM på servicenivån Naturligtvis kan varje tjänst ha en eller flera operationer. WSAS låter dig hantera MTOM på samma nivå som visas i Figur 4. Observera att MTOM på varje nivå har tre möjliga värden: true, false och optional. Om egenskapen är satt till sant skickar tjänsten ett optimerat meddelande vid behov, dvs när binär data ingår. Om värdet är inställt på falskt kommer optimering aldrig att användas, och bas 64-kodning kommer att användas för binär data. Om det är valfritt, optimerar WSAS om och endast om förfrågan kom in optimerades. Typ av förfrågan anger WSAS om den ska använda MTOM eller inte. Varför behöver vi denna typ av flexibilitet Som tidigare nämnts är det ofta fördelaktigt att använda bas 64-kodning på små filer. Således kan du bestämma att vissa operationer ska använda MTOM och andra ska inte. Eller om du kan göra det valfritt vid en operation, gör du en kontroll för storleken på data som skickas, och välj sedan att åsidosätta standard MTOM om filen är liten. Då skickar du MTOM. Låt oss se hur lätt WSAS gör det för att skicka ett MTOM-meddelande från en webbtjänstklient. Skapa en SOAP-klient som skickar MTOM-meddelanden Skicka ett MTOM-meddelande från en klient är lika enkelt som att skicka ett MTOM-meddelande från en webbtjänst. Axis2 ger flera praktiska API. Ett exempel visas i Listing 6. Listing 6. Klientkod för att skicka MTOM-meddelande Som du kan se i Listing 6 är det viktigaste att göra det möjligt att aktivera MTOM i alternativ för webbtjänsten. När du väl har gjort det, kommer Axis2 att optimera alla binära data som du skickar till webbtjänsten med hjälp av MTOM automatiskt. Weve sett hur man skickar MTOM-meddelanden från en webbtjänst och till en webbtjänst, nu kan vi titta på hur man arbetar med data som har skickats med hjälp av MTOM. Hantera ett MTOM-meddelande i en webbtjänst Nu kan vi anta att du har en webbtjänst som accepterar binär data som en del av ett SOAP-meddelande från en klient. Om din webbtjänst körs på WSAS behöver du inte göra något speciellt för att kunna hantera optimerad binär data från dina kunder. Dina kunder kan skicka SOAP-meddelanden som använder MTOM eller Base 64-kodning. Dess alla sömlösa med WSAS. Listning 7 visar ett exempel på att ta emot optimerade data. Listning 7. Webbservicemottagning Optimerad SOAP Såsom vi såg tidigare behandlar Axiom API den binära data som en textnod. Detta möjliggör ett enda API för hantering av optimerade och icke optimerade (Base 64-kodade) data. Du kommer helt enkelt åt DataHandler som är associerad med texten noden (som innehåller binär data) och använder det för att få en InputStream. När du har InputStream kan du läsa alla byte och bearbeta dem men du behöver. WSAS gör det enkelt att hantera SOAP-meddelanden med optimerade binära data nyttolaster. Låt oss se hur lätt det är att arbeta med MTOM på kunder. Hantera ett MTOM-meddelande i en klient Det finns inget magi för att hantera ett MTOM-webbservisionssvar. Weve har redan sett hur man ställer in förfrågan. I Figur 8 ser du hur man hanterar ett svar som innehåller binär data optimerad med MTOM. Återigen använder tangenten här Axiom API. Det låter oss behandla binär data som en textnod och använd sedan DataHandler för att få en InputStream till data. Återigen, när du har InputStream, kan du bearbeta data men du behöver. Weve sett hur MTOM ger den perfekta kombinationen av SOAP-standardisering och effektivitet för transport av binär data inom ett webbservicemeddelande. Weve sett hur WSO2 WSAS implementerar MTOM-specifikationen med Axis2. Weve tittade på hur man konfigurerar både webbservrar och klienter för att både skicka och ta emot MTOM-optimerade meddelanden. Nu har vi allt vi behöver för att lägga binär data till våra webbtjänster med WSO2 WSAS. Du kommer att vilja ladda ner WSO2 WSAS. Läs om de senaste funktionerna i WSO2 WSAS 2.0. Lär dig av och interagera med WSO2-communityen på WSAS Wiki. Lär dig om att exponera dina tjänster som webbtjänster enkelt med Axis2. Lär dig hur Axis2 kan aktivera dina SOA-mönster i developerWorks-artikeln SOA med Axis2. Läs mer om Axis interoperabilitet med andra webbtjänster implementeringar i denna post i TSS Interoperability blogg. Dyk in i AXIOM API i developerWorks artikeln Få ut det mesta av XML-bearbetning med AXIOM. Läs allt om XOP och MTOM i denna blogginlägg av Mark Nottingham. Interoperabilitet är namnet på spelet när det gäller webbtjänst, så lär dig mer om att använda MTOM med i artikeln Skicka filer i bitar med MTOM Web Services och 2.0. Om författaren Michael Galpin är en arkitekt på eBay i San Jose, CA. Hes har utvecklat programvara sedan 1998 och har en examen i matematik från California Institute of Technology.
No comments:
Post a Comment