Obsługa danych binarnych z osią 2 (MTOMSwA) Wprowadzenie Pomimo elastyczności, interoperacyjności i globalnej akceptacji XML, czasami, gdy serializowanie danych w XML nie ma sensu. Użytkownicy usług sieci Web mogą chcieć przesyłać binarne załączniki różnego rodzaju, takie jak obrazy, rysunki, dokumenty XML itp. Wraz z komunikatem SOAP. Takie dane są często w szczególnym formacie binarnym. Tradycyjnie wykorzystano dwie techniki w odniesieniu do nieprzezroczystych danych w XML Wysyłanie danych binarnych według wartości uzyskuje się przez osadzenie nieprzejrzystych danych (oczywiście po pewnej formie kodowania) jako elementu elementów lub atrybutu składnika XML danych. Główną zaletą tej techniki jest to, że daje ona aplikacjom możliwość przetwarzania i opisu danych, opartych jedynie na składniku XML danych. XML obsługuje nieprzezroczyste dane jako zawartość za pomocą kodu bazowego w formacie Base64 lub szesnastkowym. Obie techniki zwiększają rozmiar danych. W przypadku kodowania UTF-8 bazującego na kodowaniu tekstu kodowanie w base64 zwiększa rozmiar danych binarnych o współczynniku 1.33x oryginalnego rozmiaru, podczas gdy szesnastkowe kodowanie rozszerza dane o współczynnik 2x. Powyższe czynniki zostaną podwojone, jeśli zostanie użyte kodowanie UTF-16. Również niepokojący jest koszt ogólny kosztów przetwarzania (zarówno rzeczywistych, jak i postrzeganych) dla tych formatów, zwłaszcza podczas dekodowania z powrotem na surowy binarny. Wysyłanie danych binarnych przez odwołanie uzyskuje się przez przyłączenie czystych danych binarnych jako zewnętrznych nieopublikowanych jednostek ogólnych poza dokumentem XML, a następnie osadzanie odnośnych identyfikatorów URI w tych elementach jako elementów lub wartości atrybutów. Zapobiega to niepotrzebnemu rozkwitaniu danych i marnowaniu mocy obliczeniowej. Podstawową przeszkodą w używaniu tych nieopakowanych podmiotów jest ich duża zależność od DTD, co utrudnia modułowość oraz wykorzystanie przestrzeni nazw XML. W świecie usług internetowych wprowadzono kilka specyfikacji, które umożliwiłyby rozwiązanie problemu związanego z binarnym załączaniem przy użyciu techniki cytowania referencyjnej. SOAP z załącznikami jest jednym z takich przykładów. Ponieważ SOAP zakazuje deklaracji typu dokumentu (DTD) w wiadomościach, prowadzi to do problemu, że nie reprezentuje danych jako części inforetu wiadomości, tworząc więc dwa modele danych. Ten scenariusz jest taki, jak wysyłanie załączników z wiadomością e-mail. Nawet jeśli te załączniki są powiązane z treścią wiadomości, nie są one w środku wiadomości. Powoduje to, że technologie przetwarzają i opisują dane w oparciu o składnik XML danych w celu nieprawidłowego działania. Jednym z przykładów jest WS-Security. Gdzie MTOM wchodzi w MTOM (mechanizm przekazywania wiadomości SOAP) to kolejna specyfikacja, która koncentruje się na rozwiązaniu problemu z asystencją. MTOM stara się wykorzystać zalety powyższych dwóch technik, próbując połączyć te dwie techniki. MTOM jest w rzeczywistości metoda kwerendy referencyjnej. Format przewodu komunikatu zoptymalizowanego przez MTOM jest taki sam, jak komunikat SOAP z załącznikami, co czyni go wstecznie kompatybilnym z punktami końcowymi SwA. Najważniejszą cechą MTOM jest użycie elementu XOP: Include, który jest zdefiniowany w specyfikacji XML Binary Optimized Packaging (XOP), aby odwoływać się do załączników binarnych (zewnętrznych nieprzypisanych ogólnych podmiotów) wiadomości. Przy użyciu tego wyłącznego elementu dołączona binarna treść logicznie staje się inline (wartością) z dokumentem SOAP, mimo że jest faktycznie dołączona oddzielnie. To łączy obie światy, umożliwiając pracę tylko z jednym modelem danych. Dzięki temu aplikacje mogą przetwarzać i opisywać, patrząc jedynie na część XML, co zależy od DTD. W lekkiej notatce MTOM wystandaryzowało mechanizm odwoławczy SwA. Poniżej znajduje się wyciąg ze specyfikacji XOP. Na poziomie konceptualnym te dane binarne mogą być traktowane jako kodowane w bazie Base64 w dokumencie XML. Ponieważ ta forma konceptualna może być potrzebna podczas przetwarzania dokumentu XML (na przykład do podpisywania dokumentu XML), konieczne jest posiadanie wzajemnej korespondencji między plikami XML a pakietami XOP. Dlatego teoretyczna reprezentacja takich danych binarnych jest taka, jakby była szyfrowana base64, używając kanonicznej leksykalnej postaci bazy danych XML64 Schema (zobacz Schemat XML Część 2: Datatypes Second Edition 3.2.16 base64Binary). W odwrotnym kierunku XOP może optymalizować tylko dane w formacie Infoset zakodowane w formacie Base64, które są w kanonicznej formie leksykalnej. Apache Axis2 obsługuje kodowanie Base64. SOAP z załącznikami i MTOM (mechanizm optymalizacji transmisji wiadomości SOAP). MTOM z programowaniem Axis2 Model AXIOM jest (i może być pierwszym) modelem obiektów, który może przechowywać dane binarne. Ma tę zdolność, ponieważ OMText może przechowywać surową zawartość binarną w postaci javax. activation. DataHandler. OMText został wybrany w tym celu z dwóch powodów. Jednym z nich jest to, że XOP (MTOM) może zoptymalizować tylko dane w formacie Infoset zakodowane w formacie Base64, które są w kanonicznej leksykalnej formie typu bazowego XML64. Drugą jest zachowanie informacji zarówno w nadawce, jak iw odbiorniku. (Aby zachować zawartość binarną w tym samym typie obiektu niezależnie od tego, czy jest zoptymalizowana czy nie). MTOM umożliwia selektywne szyfrowanie fragmentów wiadomości, co umożliwia nam wysyłanie bazodajnych danych oraz dołączonych zewnętrznie surowych danych binarnych, do których ma zostać wysłany komunikat SOAP, przywołany przez element quotXOPquot (zoptymalizowana zawartość). Można określić, czy węzeł OMText, który zawiera surowe dane binarne lub binarne dane z bazy64, jest kwalifikowany do optymalizacji w czasie budowy tego węzła lub później. Aby uzyskać optymalną wydajność MTOM, zaleca się wysłanie mniejszych załączników binarnych przy użyciu kodów bazowych (nie zoptymalizowanych) i większych załączników jako zoptymalizowanych treści. Ponadto użytkownik może utworzyć optymalizowany węzeł zawartości binarnej przy użyciu ciągów szyfrujących base64, który zawiera zakodowaną treść binarną, podawaną z typem MIME rzeczywistej reprezentacji binarnej. Axis2 używa javax. activation. DataHandler do obsługi danych binarnych. Wszystkie zoptymalizowane węzły zawartości binarnej będą seryjnie traktowane jako ciągi Base64, jeśli nie jest to dozwolone w programie quotMTOM. Można także utworzyć węzły treści binarnych, które w żadnym przypadku nie będą optymalizowane. Będą one serializowane i wysyłane jako Struny Base64. Włączanie optymalizacji MTOM po stronie klienta W opcji, podczas wysyłania wiadomości należy ustawić właściwość quotenableMTOMquot na True. Jeśli ta właściwość zostanie ustawiona na wartość Prawda, każda koperta SOAP, niezależnie od tego, czy zawiera optymalizującą treść, czy nie, zostanie spersonalizowana jako komunikat MIME zoptymalizowany pod kątem MTOM. Axis2 porządkuje wszystkie węzły treści binarnych jako łańcuchy kodowane w Base64, niezależnie od tego, czy są kwalifikowane do zoptymalizowania czy nie, jeśli właściwość quotenableMTOMquot jest ustawiona na False. jeśli koperta zawiera dowolne elementy informacyjne o nazwie xop: Dołącz (zobacz binarne zoptymalizowane pakowanie w formacie XML-2. Struktury danych XOP). Użytkownik nie musi nic określić, aby Axis2 mógł odbierać wiadomości optymalizowane przez MTOM. Axis2 automatycznie zidentyfikuje i odczepia odpowiednio, jak i kiedy pojawi się komunikat MTOM. Włączanie optymalizacji MTOM po stronie serwera Serwer Axis 2 automatycznie identyfikuje przychodzące komunikaty zoptymalizowane pod kątem zgodności z MTOM w oparciu o typ zawartości i dezaktualizuje je odpowiednio. Użytkownik może włączyćMTOM po stronie serwera dla wiadomości wychodzących. Aby włączyć globalnie usługa globalnie we wszystkich usługach, użytkownicy mogą ustawić parametr quotenableMTOMquot na True w osi Axis2.xml. Gdy jest ustawione, wszystkie wychodzące wiadomości będą serializowane i wysyłane jako wiadomości MIME zoptymalizowane przez MTOM. Jeśli nie jest ustawione, wszystkie dane binarne w węzłach zawartości binarnej będą serializowane jako łańcuchy kodowane w Base64. Ta konfiguracja może być nadpisana w services. xml na podstawie usługi i operacji. Po ustawieniu tego parametru należy ponownie uruchomić serwer. Uzyskiwanie dostępu do otrzymanych danych binarnych (przykładowy kod) Im pisania prostego serwera sieci web w python, który pozwala użytkownikowi na przesyłanie pliku przy użyciu wieloparametrowych danych. O ile mi wiadomo, multipart dane MIME ma być liniowy. Na przykład granica musi znajdować się na początku linii. Nie mogę zrozumieć, w jaki sposób binarne dane są obsługiwane w tym zakresie. Mój klient (Firefox) nie jest kodowany w 7-bitowym ASCII lub cokolwiek, jest to tylko surowe dane binarne jego wysyłania. Czy dzieli dane na linie w dowolnych lokalizacjach Czy istnieje maksymalna długość linii określona dla danych wielostronnych Ive próbował przeszukiwać RFC dla wielu danych-danych, ale nic nie znalazł. zapytał 27 marca o godzinie 16:54 Po wykopaniu RFC, myślę, że w końcu dostałem to wszystko w mojej głowie. Części ciała (tj. Zawartość ciała w pojedynczej części wiadomości wieloczęściowej) muszą mieć tylko linię, ponieważ granica na końcu części zaczyna się od CRLF. Ale w przeciwnym razie dane nie muszą być oparte na linii, a jeśli zawartość ma się w niej w linii, nie ma żadnej odległości między nimi, ani też nie trzeba ich unikać (dobrze, chyba że Content-Transfer - Kodowanie jest ciągiem znaków). 7-bitowe, 8-bitowe i binarne opcje Content-Transfer-Encoding nie wykazują, że na danych zostały wykonane wszystkie dane (a zatem nie ma potrzeby cofania kodowania), mają one właśnie wskazywać typ danych można spodziewać się zobaczyć w części ciała. To, na co miałem na myśli moje słabe pytanie, polegało na odczytywaniu danych z gniazda, dzięki czemu mogłem upewnić się, że złapałem granicę i bez konieczności posiadania arbitralnie dużego bufora (np. Jeśli nie wystąpiły błędy linii treść, a więc linia readline skończyła się buforowaniem całej rzeczy). To, co skończyło, to buforowanie z gniazda z linią readline przy użyciu maksymalnej długości, więc bufor nigdy nie był dłuższy niż ten, ale również upewnić się, że zakończy się, jeśli napotkano na linię. Zapewniło to, że kiedy nadejdzie granica (po CRLF), byłaby na początku buforu. Musiałem zrobić trochę dodatkowych monkeying dookoła, aby upewnić się, że nie zawierają tego ostatecznego CRLF w rzeczywistej treści ciała, ponieważ zgodnie z RFC jego wymagane przed granicą, a tym samym nie częścią samej treści. odpowiedziało kwi 5 13 at 12:02 Spróbuj przeanalizować RFC 2045. Zwykle zawartość binarna jest konwertowana na BASE64 przez aplikację i dołączona do wiadomości wieloczęściowej za pomocą Content-Transfer-Encoding. Base64. Istnieją inne mechanizmy przekazywania danych binarnych, ale jest to dość powszechne. Dane binarne są konwertowane na oktety i wyrysowane w długich łańcuchach długości (w zależności od wariantu kodowania - patrz łącze BASE64 powyżej). Aplikacja odbiorcza następnie dekoduje ją w oryginalnej zawartości binarnej. Nie jestem programistą Pythona, ale byłbym zaskoczony, że naprawdę musiałeś sam kodować. Podejrzewam, że istnieją wstępnie zbudowane funkcje biblioteki Pythona, aby to zrobić dla Ciebie. Odpowiedziałem, Mar 27 13 w 17:43 Dzięki, patrzyłem na inny RFC co nie było tak pouczające. Znalazłem także RFC 2046, który definiuje szczegółowe wiadomości w sekcji 5. Zauważ, że w tych RFC są nieco subtelne: mówi się, że wiadomości wielopiętrowe nie mogą mieć kodowań innych niż binarne, 8-bitowe i binarne (tj. nie Base-64). Niemniej jednak, mówi się, że poszczególne części w obrębie wielu części mogą mieć własne kodowanie treści, więc masz rację, że Base-64 jest możliwe. ndash brianmearns Mar 28 13 at 13:20 Your Answer 2017 Stack Exchange, IncSending Attachments z aplikacjami SOAP SOAP często muszą zajmować się nie tylko prostymi wiadomościami. Ładunek komunikatu SOAP może często zawierać edytor tekstu lub dokument PDF, obraz lub inny plik binarny. W tym artykule wyjaśniono, jak używać mechanizmu optymalizacji transmisji wiadomości (MTOM) do wysyłania i odbierania tych wiadomości. Pobierz bezpłatną poradę Podręcznik: Java App Development w inżynierii oprogramowania Cloud zbliża się do projektowania i projektowania przedsiębiorstw w całkowicie nowy sposób, dzięki chmurze. W tym podręczniku ekspertów zbadaj, jak Twoi rówieśnicy wykorzystują chmurę, aby usprawnić zarządzanie cyklem życia aplikacji, zaoszczędzić pieniądze i sprawić, że produkcja i bezpieczeństwo są wydajniejsze. Poprzez przesłanie Twoich danych osobowych zgadzasz się, że firma TechTarget i jej partnerzy mogą się z Tobą skontaktować, jeśli chodzi o treść, produkty i oferty specjalne. Zgadzasz się również, że Twoje dane osobowe mogą być przesyłane i przetwarzane w Stanach Zjednoczonych oraz przeczytać i zaakceptować Warunki Użytkowania i Politykę Prywatności. Wymagania wstępne W tym artykule użyto WSO2 Web Services Application Server (WSAS). Zaleca się pobranie i zainstalowanie WSO2 WSAS 2.0. W artykule użyto wydania serwletu zainstalowanego w Apache Tomcat. Każdy serwer aplikacji może być używany z wersją serwletu, postępuj zgodnie z instrukcjami dołączonymi do WSO2 WSAS. W ogóle nie musisz używać serwera aplikacji, ponieważ WSO2 WSAS działa świetnie w samodzielnym formacie. WSO2 WSAS wymaga Java 1.4 lub 1.5, ale nie ma innych warunków wstępnych. Oczywiście usługi sieciowe i SOAP są używane, więc znajomość tego pomoże. Kiedy nie wystarczy XML: dane binarne Istnieją nieskończone sposoby przesyłania danych przez sieć. Istnieje wiele protokołów i formatów danych. Standaryzacja wokół SOAP zabrała wiele zgadywania w przesyłaniu danych między systemami. SOAP standaryzuje protokół (HTTP) i format danych (XML). Jedną z głównych krytyków SOAP jest użycie XML. XML jest oparty na tekście. To nie tylko dla dużych wiadomości, ale czyni to niezgodnymi z danymi binarnymi. Na przykład powiedzmy, że Twoja wiadomość musi zawierać zdjęcie. Stwarza to problem, gdy format wiadomości jest tekstem. Łączenie danych binarnych z SOAP Ok, więc musisz wysyłać dane binarne między aplikacjami. Chcesz używać SOAP, ale jest ograniczony do tekstu. Więc powinieneś po prostu zrezygnować z SOAP wszystkich razem Oczywiście nie, jest zbyt wiele korzyści dla SOAP. Wystarczy, że połączysz je z danymi binarnymi. Widzisz strony internetowe robią to cały czas, że nie może być tak trudne, dobrze Pozwala badać niektóre rozwiązania tego problemu. Jednym ze sposobów możesz spróbować po prostu zrzucić binarny w węzeł tekstowy. Może to wyglądać tak, jak Listing 1. Listing 1. XML z danymi binarnymi: pierwsze próby Pamiętaj, że znaki są również bajtami, podobnie jak binarne dane. Parser XML, niezależnie od tego, czy jest to analizator składni DOM, SAX czy StAX, musi używać kodowania zestawu znaków do tłumaczenia wszystkich bajtów w dokumencie jako znaków. Więc nasze dane binarne mogą mieć znaki, które odpowiadają zastrzeżonym znakom XML, np. Lt lub gt lub amp. Każda taka sekwencja bajtów w powyższym węźle tekstowym spowoduje, że parser po drugiej stronie zerwie. Takie podejście nie zadziała. Ale poczekaj, może to jest sposób na rozwiązanie tego podejścia. Co z używaniem bloku CDATA Powoduje, że analizator składni ignoruje znaki wewnątrz bloku. To zmodyfikowane podejście może wyglądać tak, jak Listing 2. Listing 2. XML z binarnym użyciem dysku CDATA Jeśli mamy bajty, które byłyby interpretowane jako gt (na przykład), zostaną one zignorowane. Jednak analizator składów musi dowiedzieć się, gdzie kończy się sekcja CDATA. Robi to, szukając sekwencji bajtów odpowiadających znakom gt. Może to wydawać się nieprawdopodobne, ale nasze dane binarne mogą mieć taką sekwencję bajtów w środku. To spowodowałoby, że dowolny parser pomyśli, że sekcja CDATA się skończyła, a kolejne postacie będą interpretowane tak samo jak w naszej pierwszej próbie. To też nie będzie działać. Potrzebujemy sposobu, aby upewnić się, że te bajty nie są interpretowane wcale. Kodowanie w bazie 64: Działa, ale rozbudowane Jest rozwiązanie tego wariantu naszego problemu. Jedynym sposobem na to jest użycie kodowania Base 64. Ta technika była od lat 80-tych (jako standard). Wiąże się to z użyciem alfabetu 64-znakowego składającego się z małych liter, a-z, wielkich liter, A-Z, cyfr 0-9 i symboli. Każdy bajt jest odwzorowywany na te znaki, więc nie ma sposobu, aby żaden bajt mógł zostać błędnie interpretowany jako coś, co mogłoby dławić analizator składni XML. Więc rozwiązano problem, tak Tak, ale to raczej niewydajne rozwiązanie. Binarne szyfrowane baza 64 szyfr są średnio o 37 większych (liczba bajtów) niż surowe, niezakodowane dane binarne. Ponadto, analizator składni po drugiej stronie musi wiedzieć o kodowaniu tak, aby mógł dekodować ładunek. Można sobie wyobrazić, że jeśli kodowanie w bazie 64 jest częścią standardów SOAP, wtedy byłby jakiś standardowy sposób wskazania tych procesorów SOAP. Tak się jednak nie stało. Może to być rozwiązanie, ale jest zarówno nieskuteczne, jak i niestandardowe. Potrzebujemy czegoś bardziej efektywnego i ujednoliconego. SOAP z załącznikami: działa, ale wadliwy projekt Jednym z rozwiązań tego problemu jest użycie tego, co jest znane jako SOAP z załącznikami. Chodzi o to, aby po prostu umieścić dane binarne poza komunikat SOAP całkowicie. Rysunek 1 zapewnia miłą wizualizację tego. Rysunek 1. SOAP z załącznikami Jest to bardzo podobne do tego, jak binarne pliki można dołączyć do wiadomości e-mail. Komunikat SOAP zawiera odniesienie do pliku binarnego, który jest dołączony do wiadomości. Jest to zarówno bardziej efektywne, jak i standardowe, ale ma pewne wady w jego konstrukcji. Binarne załączniki nie są w ogóle częścią wiadomości SOAP. Jest podobny na wiele sposobów, aby po prostu przesłać identyfikator URI dla danych binarnych i pozostawić go do procesora komunikatów w celu pobrania rzeczywistych danych binarnych. Pokazuje pewne rzeczywiste problemy w takich sprawach jak WS-Security. Nadal jednak to było używane przez chwilę, dopóki nie zaproponowano lepszego rozwiązania: MTOM. MTOM: najlepsze z obu światów MTOM oznacza mechanizm SOAP Message Transmission Optimization Mechanism. Łączy skuteczność SOAP z załącznikami, ale tak nie bez złamań danych binarnych poza komunikatem SOAP. Jak to możliwe? Klucz jest technologia zwana XML-binarnym Optymalizowanym Pakowaniem lub XOP. XOP umożliwia włączenie danych binarnych w ramach pliku XML. W rzeczywistości XML Infoset staje się supersetiem tradycyjnego pakietu informacyjnego, znanego jako plik XOP. Pozwala na przechowywanie danych binarnych poza dokumentem XML, tak jak w SOAP z załącznikami. Używa specjalnego elementu XOP: include, aby poinformować procesora o zastąpieniu zawartości bazującymi na danych binarnych, a tym samym o zamykaniu logiki dyskretnego przechowywania i pobierania danych binarnych. Ta logika staje się nieodłącznie związana z parserem XML i pozwala parserowi SOAP traktować dane binarne jako część dokumentu XML bez specjalnej logiki wyszukiwania. Podobnie pozwala serwerowi SOAP na utworzenie komunikatu SOAP w sposób jednolity, nie ma specjalnej logiki wykrywania tych danych binarnych z komunikatu SOAP. MTOM w WSO2 WSAS Weve wiele mówił o potrzebie MTOM io tym, jak powinno działać w teorii. To nie robi nam wiele dobrego bez prawdziwej implementacji. Na szczęście istnieje łatwy sposób na uzyskanie doskonałej implementacji MTOM, wystarczy użyć WSO2 WSAS. WSO2 WSAS jest oparty na sprawdzonych i sprawdzonych technologiach, w tym Apache Axis2. Axis2 daje WSO2 WSAS swoją implementację MTOM. Pozwala spojrzeć na to, jak wykorzystać moc wdrażania WSASAxis2s MTOM. Wysyłanie komunikatu MTOM z usługi sieci Web przy pomocy obsługi API Axiom MTOM na platformie Axis2 opiera się na tych samych klasach, które są używane przez Axis2. Wykorzystuje model obiektowy Axis2s (OM). Axis2 obsługuje zarówno kodowanie Base64, jak i MTOM, co ułatwia przełączanie między nimi. Dlaczego dobrze dla bardzo małych plików, może być bardziej skuteczne w użyciu kodowania Base64. Aby osiągnąć to płynne przełączanie pomiędzy zoptymalizowanym i nieoptymalizowanym transportem, Axis2 traktuje dane binarne jako węzeł tekstowy XML. Jedyna różnica polega na tym, że należy przejść do javax. activation. DataHandler w celu uzyskania dostępu do danych, jak pokazano na listingu 3. Listing 3. Dodawanie danych binarnych za pomocą interfejsu API Axiom W przykładzie z listingu 3 javax. activation. FileDataSource jest używany do udostępniania DataHandler z dostępem do danych binarnych. Możesz użyć dowolnej klasy, która implementuje interfejs javax. activation. DataSource. Na przykład podczas pracy z obrazami można użyć org. apache. axis2.attachments. ImageDataSource. Implementuje interfejs DataSource i może być wygodniejszy podczas pracy z obrazami. W jaki sposób Axis2, a tym samym WSO2 WSAS, wiedzą, że używa MTOM do optymalizacji danych binarnych, które są w zasadzie założone przez Axis2. Można ręcznie nadpisać to przez dodanie tylko jednej linii kodu, jak pokazano na listingu 4. Listing 4. Wyłączenie MTOM Ta pojedyncza linia kodu spowoduje, że Axis2 nie zoptymalizuje, tzn. Nie używaj MTOM. Tak więc Axis2 będzie używać kodowania Base 64 do danych binarnych i będzie to węzeł tekstowy. W przeciwnym razie MTOM zacznie kopać, a XOP będzie używane do optymalizacji transportu danych binarnych w komunikacie SOAP. Włączanie MTOM na serwerze Oczywiście, aby uzyskać wszystkie te wspaniałe, automatycznie zoptymalizowane działanie, musisz włączyć MTOM. Możesz to zrobić za pomocą pliku osi2.xml bardzo łatwo, jak pokazano na listingu 5. Listing 5. Włączanie MTOM w osi. xml Nie może być bardziej bezbolesne niż to, prawe Jest to ustawienie globalne i jest ustawieniem domyślnym na WSO2 WSAS. Możesz rzeczywiście umożliwić MTOM na czterech różnych poziomach: globalnym, grupowym, usługowym i operacyjnym. Używasz tej samej semantyki na każdym poziomie. Za pomocą Konsoli zarządzania można zarządzać MTOM na każdym z tych poziomów. Przykładowo spójrz na rysunek 2. Rysunek 2. Zarządzanie MTOM na poziomie grupy usług Tutaj widzimy MTOM zarządzany na poziomie Grupy Usług. Każda usługa w grupie może być indywidualnie zarządzana, jak pokazano na rysunku 3. Rysunek 3. Zarządzanie MTOM na poziomie usługi Oczywiście każda usługa może mieć jedną lub więcej operacji. WSAS umożliwia zarządzanie MTOM na tym poziomie, jak pokazano na rysunku 4. Zauważ, że na każdym poziomie MTOM ma trzy możliwe wartości: true, false i opcjonalne. Jeśli właściwość jest ustawiona na wartość true, usługa będzie wysyłać zoptymalizowaną wiadomość, gdy jest to konieczne, tzn. Gdy dane binarne są dołączone. Jeśli wartość jest ustawiona na wartość false, optymalizacja nigdy nie będzie używana, a dla dowolnych danych binarnych będzie używany kodowanie Base 64. Jeśli opcja ta jest ustawiona na opcjonalną, WSAS zoptymalizuje, czy i tylko w przypadku, gdy żądanie zostało zgłoszone. Typ żądania wskazuje WSAS, jeśli powinien używać MTOM, czy nie. Dlaczego potrzebujemy tego rodzaju elastyczności Jak wspomniano wcześniej, często korzystne jest użycie kodowania Base 64 w małych plikach. Można więc zdecydować, że niektóre operacje powinny używać MTOM, a inne nie powinny. Lub możesz to zrobić opcjonalnie w operacji, programowo wykonaj sprawdzanie rozmiaru wysyłanych danych, a następnie wybierz nadpisanie domyślnego MTOM, jeśli plik jest mały. Wtedy wysyłasz MTOM. Pozwala sprawdzić, jak łatwo WSAS sprawia, że wysyła komunikat MTOM z klienta usług sieciowych. Tworzenie klienta SOAP, który wysyła komunikaty MTOM Wysłanie komunikatu MTOM z klienta jest równie łatwe, jak wysyłanie wiadomości MTOM z usługi sieciowej. Axis2 udostępnia kilka wygodnych interfejsów API. Przykład jest pokazany na listingu 6. Listing 6. Kod klienta do wysłania komunikatu MTOM Jak widać na listingu 6, najważniejszą sprawą jest włączenie MTOM w opcjach klienta usługi sieciowej. Gdy to zrobisz, Axis2 zoptymalizuje wszelkie dane binarne, które wysyłasz do usługi sieciowej przy użyciu MTOM automatycznie. Jak widać, jak wysyłać wiadomości MTOM z usługi sieciowej i do usługi internetowej, teraz można sprawdzić, jak pracować z danymi, które zostały wysłane przy użyciu MTOM. Obsługa komunikatu MTOM w usłudze sieci Web Załóżmy teraz, że masz usługę internetową, która akceptuje dane binarne w ramach wiadomości SOAP z klienta. Jeśli usługa sieciowa jest uruchomiona w systemie WSAS, nie musisz robić nic specjalnego, aby móc obsługiwać zoptymalizowane dane binarne od klientów. Twoi klienci mogą wysyłać wiadomości SOAP z kodowaniem MTOM lub Base64. Wszystko jest płynne dzięki WSAS. Listing 7 pokazuje przykład otrzymywania zoptymalizowanych danych. Listing 7. Odbiór usług internetowych Zoptymalizowany SOAP Jak widzieliśmy wcześniej, Axiom API traktuje dane binarne jako węzeł tekstowy. Umożliwia to pojedynczy interfejs API do obsługi zoptymalizowanych i nie zoptymalizowanych (bazowanych na Base64) danych. Po prostu uzyskiwany jest dostęp do modułu DataHandler skojarzonego z węzłem tekstowym (zawierającym dane binarne) i użyj go, aby uzyskać InputStream. Gdy już masz InputStream, możesz przeczytać wszystkie bajty i przetworzyć je, ale musisz. WSAS ułatwia obsługę komunikatów SOAP z zoptymalizowanymi ładunkami danych binarnych. Pozwala spojrzeć na to, jak łatwo jest pracować z MTOM na klientach. Obsługa komunikatu MTOM w kliencie Nie ma magii w obsłudze odpowiedzi usługi sieciowej MTOM. Widzieliśmy już, jak skonfigurować żądanie. Na rysunku 8 widać jak radzić sobie z odpowiedzią, która zawiera dane binarne zoptymalizowane pod kątem MTOM. Ponownie klucza używa Axiom API. Pozwala traktować dane binarne jako węzeł tekstowy, a następnie użyć DataHandler, aby uzyskać dane wejściowe InputStream. Ponownie, gdy już masz InputStream, możesz przetworzyć dane, których potrzebujesz. Widzieliśmy, jak MTOM zapewnia doskonałe połączenie standaryzacji i efektywności SOAP w celu przesyłania danych binarnych w wiadomości usługi internetowej. Widzieliśmy, jak WSO2 WSAS implementuje specyfikację MTOM przy użyciu Axis2. Spójrzmy na pytanie, jak skonfigurować zarówno serwery usług internetowych, jak i klienci, aby wysyłać i odbierać wiadomości zoptymalizowane pod kątem MTOM. Teraz mamy wszystko, czego potrzebujemy, aby dodać dane binarne do naszych usług internetowych przy użyciu WSO2 WSAS. Chcesz pobrać WSO2 WSAS. Przeczytaj najnowsze funkcje WSO2 WSAS 2.0. Ucz się i współdziałaj z społecznością WSO2 na Wiki WSAS. Dowiedz się, jak łatwo udostępniać usługi Axis2 jako usługi sieciowe. Dowiedz się, w jaki sposób Axis2 może umożliwić projektowanie architektury SOA w artykule SOHO w developerWorks z Axis2. Dowiedz się wszystkiego o współdziałaniu Axis z innymi implementacjami usług internetowych w tym wpisie w blogu TSS Interoperability. Zanurkuj się w AXIOM API w artykule developerWorks Poznaj jak najwięcej z przetwarzania XML przy użyciu AXIOM. Przeczytaj wszystkie informacje o XOP i MTOM w tym blogu Mark Nottingham. Interoperacyjność jest nazwą gry w przypadku usługi sieciowej, więc dowiedz się więcej o używaniu MTOM z artykułem Wysyłanie plików w kawałkach z usługami sieciowymi MTOM i 2.0. O autorze Michael Galpin jest architektem w serwisie eBay w San Jose w Kalifornii. Od 1998 roku zajmuje się oprogramowaniem i posiada tytuł magistra matematyki w California Institute of Technology.
No comments:
Post a Comment