Technologie Internetu wykład 13: Web Services: opisy i rejestry usług Piotr Habela

1. Technologie Internetu wykład 13:Web Services: opisyi rejestry usług Piotr Habela Polsko-Japońska Wyższa Szkoła Technik Komputerowych 1

2. W poprzednim odcinku… • Web Services stanowią rozwinięcie koncepcji technologii rozproszonych obiektów. • Wysoki stopień ich niezależności od platformy stwarza realne szanse na wyjście z systemami rozproszonymi poza granice danej firmy. • Kluczem do współdziałania jest XML jako język wymiany danych. Oparto na nim protokół SOAP, służący komunikacji z usługami Webu. Umożliwia on współdziałanie przy zachowaniu niezależności od języka programowania i infrastruktury rozproszonych obiektów. • SOAP umożliwia realizację różnego stylu interakcji, włącznie z komunikatami asynchronicznymi i modelem RPC. SOAP nie determinuje protokołu transportowego – przewidziane są różne wiązania. Z drugiej strony nie określa też semantyki interakcji. 2

3. Plan wykładu • Architektura Web Services • Problem opisu usług • Charakterystyka języka WSDL • Rejestry opisów usług – specyfikacja UDDI • ebXML – nowa technologia elektronicznej wymiany dokumentów • Podsumowanie architektury Web Services 3

4. Właściwości Web Services • Usługi mogą być różnorodne – zarówno czysto niematerialne (udostępnianie informacji), jak i mające skutki w świecie materialnym. Np.: • autoryzacja kart kredytowych; • wyliczenia należnych opłat/podatków; • usługa wydruku (dla urządzeń przenośnych). • Zależnie od okoliczności, różnią się też scenariusze budowy usług: • Usługa jest projektowana, tworzony jest jej opis a następnie generuje się odpowiedni kod („pieńki” i „szkielety”) i implementuje jej funkcjonalność; • Usługa powstaje poprzez obudowanie odpowiednim interfejsem istniejących już komponentów aplikacji. • Aby powstała funkcjonalność była użyteczna, usługa wymaga precyzyjnego opisania. 4

5. Opis usługi Webu • Współdziałanie klienta z usługą wymaga uzgodnienia celu i mechanizmu interakcji. • Następujące motywy przemawiają za tym, aby te informacje były dostępne w maszynowo przetwarzalnej postaci: • precyzja opisu; • możliwość automatycznego generowania kodu dostępowego; • dynamiczne wyszukiwanie i użycie; • możliwość kontroli zgodności działania usługi z jej opisem. • W opisie takiej interakcji można wyróżnić oczekiwania (informacje wejściowe) oraz funkcjonalność (informacje wyjściowe) zarówno po stronie klienta jak i serwera. Warunkiem pomyślnej interakcji jest spełnienie przez obie strony swoistego kontraktu, polegającego na dopasowaniu oferowanych danych do wymagań. 5

6. Semantyka interakcji • Określa cel i znaczenie elementów interakcji. • W szczególności chodzi tu o określenie zewnętrznych w stosunku do danej interakcji efektów (np. przelew środków, dokonanie rezerwacji, sporządzenie wydruku); • Drugim istotnym zagadnieniem jest kontekst, czyli umiejscowienie danej operacji w szerszym procesie: zarówno w części realizowanej w postaci elektronicznej jak i w pozostałych fragmentach. • Jeśli działania nie są podejmowane przez człowieka, informacje te wymagają jawnego i jednoznacznego sformułowania. • Jeśli wymagana jest po prostu jednoznaczna identyfikacja jakiegoś pojęcia czy procesu, to opis może pozostać wręcz w postaci języka naturalnego, o ile zostanie z nim skojarzona jednoznaczna identyfikacja (np. poprzez URL jak w wypadku przestrzeni nazwowych). • Z drugiej strony dla umożliwienia wyszukiwania usług, potrzebny jest opis ich istotnych właściwości w postaci przetwarzalnej maszynowo. 6

7. Język WSDL (Web Services Description Language) • Specyfikacja W3C, zgodnie z nazwą służąca czytelnemu maszynowo opisowi usług Webu, opartemu na XML. • Ponieważ opisuje usługę, nie zaś wymagania klienta, stąd budowa swoistej giełdy, gdzie zarówno usługi jak i zapotrzebowania byłyby przedmiotem wyszukiwania i ew. kojarzenia przez odrębnego brokera, wymaga dodatkowo określenia sposobów opisu takich zapotrzebowań. • WSDL opisuje technikę współdziałania z usługą. Zakłada, że semantyka usługi jest opisana na zewnątrz i może być jednoznacznie wskazana poprzez identyfikator. Tym samym „kontrakt” dotyczący znaczenia i celu jest oddzielony od „kontraktu” określającego mechanikę współdziałania. • Specyfikacja zatem nie zajmuje się problemem definiowania semantyki usługi. 7

8. Zawartość dokumentu WSDL • Jest to opis abstrakcyjnego interfejsu, tj. niezależnego od protokołu transportowego oraz od języka programowania. • Struktura pliku WSDL jest zdefiniowana w specyfikacji w postaci schematów XML Schema. • Typy danych używanych w opisywanych przez dokument WSDL interfejsach mogą być zdefiniowane w dowolnym systemie typów, choć domyślnie stosuje się właśnie XML Schema. • Funkcjonalność odpowiada np. IDL ze standardu OMG CORBA. • Jak zobaczymy, opis usługi jest jednak znacznie bardziej rozbudowany. Wynika to z dwóch faktów: • większa niezależność i różnorodność możliwych do zastosowania w Web Services protokołów; • konieczność określenia wszelkich informacji konfiguracyjnych explicite (a nie jak w lokalnie tworzonych systemach, gdzie szereg ustawień może mieć charakter umowny). 8

9. Struktura dokumentu definicji • Element-korzeń nosi nazwę definitions. Zawiera atrybut name określający nazwę danej usługi. Pozostałe jego atrybuty definiują odwołania do przestrzeni nazwowych: standardowych – XML Schema, SOAP, WSDL, oraz docelowej przestrzeni nazwowej danej usługi „targetNamespace”. • Definicje mogą zawierać deklaracje importu: <import namespace= ”…” location=”…” />, służącą dekompozycji dużego opisu pomiędzy kilka plików. 9

10. Składniki dokumentu WSDL – cz. abstrakcyjna (1) • Zawartość definicji składa się z części abstrakcyjnej: • Definicje typów danych; • Definicje komunikatów; • Definicje typów portów; • …oraz części konkretnej: • Definicje wiązań; • Definicja usługi. • Element types: Zawiera definicje typów danych wykorzystywanych w komunikatach opisywanej usługi. Typy te mogą być zdefiniowane w dowolnym systemie typów, choć domyślnie stosuje się XML Schema (wówczas dla typów wbudowanych, deklarację types możemy pominąć). 10

11. Składniki dokumentu WSDL – cz. abstrakcyjna (2) • Elementy message. Każdy z nich definiuje pojedynczy komunikat przesyłany podczas realizacji usługi. Komunikat posiada nazwę (atrybut name) oraz jeden lub więcej podelementów part, odwołujących się do wbudowanych typów XML Schema albo do typów zdefiniowanych w elemencie types.Np. <message name="wePodajTemperature"> <part name="miasto" type="xs:string"/> </message> <message name="wyPodajTemerature"> <part name="temp" type="xs:float"/> </message> 11

12. Składniki dokumentu WSDL – cz. abstrakcyjna (3) • Element portType: definiuje abstrakcyjne operacje w oparciu o wcześniej opisane komunikaty. Element taki posiada nazwę oraz podelementy „input”, „output”, „fault”. Posiadają one atrybut message, odwołujący się do nazwy zdefiniowanego wcześniej komunikatu. • Dopuszczalne rodzaje komunikatów zależą od rodzaj transmisji: • request/response: wejście i wyjście (+ ew. komunikat błędu); • one-way: tylko dane wejściowe; • solicit response (żądanie odpowiedzi): najpierw dane wyjściowe, potem wejściowe (+ ew. komunikat błędu); • notification: tylko dane wyjściowe; <portType name="TemperaturyPortType"> <operation name="PodajTemperature"> <input message="tns:wePodajTemperature"/> <output message="tns:wyPodajTemperature"/> </operation> </portType> 12

13. Składniki dokumentu WSDL – cz. konkretna (1) • Element binding: dla każdego portType oferuje przynajmniej jedno wiązanie do konkretnego protokołu. Posiada nazwę (atrybut name) i następującą zawartość: • Element soap:binding: określa styl interakcji (rpc lub document) oraz określa rodzaj transportu (np. SOAP poprzez HTTP). • Element operation: zawiera podelementy odpowiadające danym wejściowym i wyjściowym i określa dla nich sposób kodowania ciała komunikatu SOAP. Zawiera również specyfikację nagłówka HTTP, jaki klient przesyła przy wywołaniu usługi. <binding name=”TemperaturyBinding” type=”tns:PodajTemperaturePortType”> <soap:binding style=”rpc” transport=”http://schemas.xmlsoap.org/soap/http” /> <operation name=”PodajTemperature”> <soap:operation soapAction=”” /> <input><soap:body use=”encoding” encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”/> </input> <output>… j.w. …</output></operation></binding> 13

14. Składniki dokumentu WSDL – cz. konkretna (2) • Element service: stanowi zbiór portów (ports), tworzących usługę. Zdefiniowany poprzez odwołania do konkretnych ich wiązań, jak określono powyżej. Określa, pod jakim adresem usługa o zdefiniowanym wcześniej wiązaniu będzie dostępna. <service name=”Temperatury”> <port name=”TemperaturyPort” bindings=”tns:TemperaturyBinding”> <soap:address location=”http://uslugi.przyklad.com:80/soap/” /> </port> </service> 14

15. Opis usług - podsumowanie • Problem niezależnego od implementacji opisu funkcjonalności elementów systemu rozproszonego znany jest już z wcześniejszych technologii jak choćby CORBA. Już w tamtej technologii zadbano o udostępnienie poprzez interfejs programistyczny tych opisów, celem umożliwienia dynamicznej konstrukcji żądań. • Aktualnie specyfikacje służące opisowi usług poprzestają na definiowaniu interfejsów dla wymiany komunikatów. Jest możliwe, że podjęte zostaną próby wprowadzenia do tej specyfikacji systemu opisu dla samej semantyki usług. 15

16. UDDI (Universal Description, Discovery and Identification) • Specyfikacja, tworzona przez konsorcjum OASIS, określa rozproszony katalog, zawierający zarówno informacje o samych firmach jak i o udostępnianych przez nie usługach Webu, czyli swoistą „książkę telefoniczną”. Rozwijając tę metaforę, specyfikacja wyróżnia: • „zielone strony”: techniczny opis usług wraz z odnośnikami URL (w założeniach nie muszą to być koniecznie usługi Webu); • „białe strony”: identyfikacja, adresy i inne dane kontaktowe firm; • „żółte strony”: wykaz firm ułożony według klasyfikacji przemysłowej; • Rejestr zaprojektowano jako logicznie scentralizowany, zaś fizycznie rozproszony i replikowany. Może być dostępny zarówno tradycyjnie (interfejs WWW), jak i programowo (jak usługi Webu). • Interfejs programistyczny wyróżnia część służącą formułowaniu zapytań oraz część służącą publikowaniu opisów. 16

17. UDDI - zastosowanie • Tego rodzaj rejestr stanowi niezbędną podstawę dla realizacji koncepcji rozwiniętej współpracy B2B opartej na Web Services. • Z rozwojem rejestrów usług wiązane są duże nadzieje. Oczekuje się, że pojawienie się ustandaryzowanych rejestrów spowoduje taki rozwój usług Webu w zastosowaniach B2B, jaki nastąpił w przypadku WWW po wprowadzeniu HTML. • Realnym celem nie jest tu zastąpienie człowieka w wyszukiwaniu usług, ale raczej podniesienie efektywności wyszukiwania (być może wspieranego przez specjalizowane wyszukiwarki), poprzez umieszczenie w jednym logicznym rejestrze jednolicie uformowanych opisów. • Oczywiście możliwe jest automatyzowanie np. konfigurowania współpracy z określonymi usługami na podstawie ich opisów w rejestrze UDDI. • Specyfikacja dostarcza podstawowych mechanizmów, stanowiąc tym samym jedynie ramę dla nadbudowy wyrafinowanych mechanizmów wyszukiwawczych (np. według ceny usług). 17

18. Budowa rejestru UDDI (1) • Specyfikacja zawiera schematy XML dla komunikatów SOAP oraz opis interejsów programistycznych rejestru. • Schematy XML (wybrane jako postać opisu z uwagi na niezależność od platformy, rozbudowany system typów oraz naturalność odwzorowania hierarchicznej informacji) definiują następujące zasadnicze typy informacji stosowane w wymianie opisów usług: • Informacja biznesowa; • Informacja o usłudze; • Specyfikacja usługi. • Informacja biznesowa: opisywana w elemencie businessEntity. Zawiera podstawowe informacje identyfikujące firmę, w tym wsparcie dla systemów klasyfikacji branżowej i geograficznej. 18

19. Budowa rejestru UDDI (2) • Informacja o usłudze: Informacja ta znajduje się wewnątrz elementu zawierającego informacje biznesowe. Składa się z elementów businessService (opis usługi) oraz bindingTemplate (informacja niezbędna dla wywołania usługi): informacje techniczne niezbędne do połączenia się z usługą; m.in. czy jest samodzielna, jej URL itp. • Specyfikacja usługi: Element bindingTemplate zawiera zbiór odnośników do specyfikacji (zawartych w elementach tModel). Każdy element tModel stanowi opis pewnej specyfikacji, na której oparta jest usługa. Komplet takich specyfikacji określa wzorzec zgodności z daną usługą. 19

20. API rejestru UDDI (1) • Umożliwia programistyczny dostęp do informacji zawartych w rejestrze. Wyróżniono części: Inquiry API (część służąca pobieraniu informacji z rejestru oraz część służąca obsłudze błędów wywołań usług) i Publisher API. • Sam rejestr UDDI jest oparty na protokole usług Webu: SOAP. Wszystkie wołania zdefiniowano jako synchroniczne. • Interfejs zapytań: • Posiada metody find_xx – umożliwiające wyszukiwanie według różnych kryteriów; • Dla opisu o znanym kluczu, która go identyfikuje, można posłużyć się metodą get_xx celem pobrania całej struktury businessEntity, businessService, bindingTemplate lub tModel. 20

21. API rejestru UDDI (2) • Scenariusz dostępu do usługi: (Każdej udostępnianej usłudze odpowiada element bindingTemplate.) • Wyszukanie podmiotu biznesowego (businessEntity), oferującego usługę. • Nawigacja lub pobranie całego elementu businessEntity. • Zachowanie informacji z wybranego bindingTemplate. • Przygotowanie programu w oparciu o dane z bindingTemplate i zawarte w nim informacje u zastosowanych specyfikacjach (umieszczonych w tModel). • Wywoływanie usługi. • Obsługa błędu wołania usług: • Dodatkową zaletą dostępności rejestru usług jest umożliwienie reagowania na błędy wołania usług. Po wykryciu błędu oprogramowanie jest w stanie zaktualizować przechowywaną kopię wpisu dotyczącą danej usługi i ponowić żądanie. Podejście to jest zwane „retry on failure”. • Pozwala np. uniknąć zakłóceń po wprowadzeniu przekierowania. 21

22. ebXML • Działalność gospodarcza wiąże się z intensywną komunikacją pomiędzy firmami. Jest rzeczą bezsporną, że przeniesienie tej wymiany do postaci elektronicznej stwarza szanse na uczynienie jej szybszą i mniej pracochłonną. • Tradycyjne rozwiązanie powstałe w tym celu: EDI (Electronic Document Interchange) stanowi jednak technologię złożoną i bardzo kosztowną. Ogranicza to jej zastosowanie do dużych korporacji. • Zastosowaniem tej specyfikacji jest zatem stworzenie ram dla prostszego, tańszego i powszechniejszego zamiennika technologii EDI. • ebXML stanowi grupę specyfikacji rozwijanych przez ONZ (United Nations Centre for Trade Facilitation and Electronic Business): UN/CEFACT, zajmującą się również specyfikacją EDI, oraz OASIS (Organization for the Advancement of Structured Information Standards). 22

23. Niezbędne rozszerzenia XML • Ów bardziej produktywny zamiennik dla EDI postanowiono oprzeć na XML, co jest motywowane następującymi czynnikami: • popularność i prostota składni; • niezależność od platformy; • szerokie wsparcie dla przetwarzania dokumentów XML. • Niezbędne jest jednak określenie, jakie dane i w jakiej postaci mają być wymieniane. • Zadanie skonstruowania elektronicznej wymiany danych wykracza znacznie poza sformułowanie składni i gramatyki wymienianych komunikatów. Potrzebne jest określenie: • opisów procesów biznesowych (Business Process Specification); • definicji i budowy wymienianych dokumentów; • formatu i protokołów wymiany danych; • udostępniania tych informacji w standardowych rejestrach. 23

24. ebXML – współdziałanie z partnerami biznesowymi • Rejestry przechowują dla danej firmy specyfikację określającą oczekiwania wobec partnerów biznesowych. Zapisy te określane są jako CPPs (Collaboration Protocol Profiles). Określają: w jakich procesach biznesowych firma jest skłonna uczestniczyć, w jakiej roli i przy jakich technicznych ograniczeniach. Np.: że świadczy usługi udostępniania określonych danych za pośrednictwem HTTP, z możliwością przyjęcia zapłaty on-line. • Kolejnym istotnym krokiem jest zestawienie określonej współpracy. Niezbędna informacja występuje w postaci CPA (Collaboration Protocol Agreement), i składa się ze skojarzonych zapisów CPP obydwu stron. Informacja ta jest uzupełniona o zagadnienia techniczne jak protokół, wymagania autentykacji itp. i pozwala zbudować i skonfigurować po obu stronach współpracujące aplikacje, zwane tu BSI (Business System Interfaces). 24

25. CPA i CPP nieco dokładniej • CPP są identyfikowane poprzez GUID (Globally Unique Identifier) i zawierają: • identyfikację firmy lub jej części; • realizowane procesy biznesowe oraz role pełnione w nich przez firmę; • informację o wykorzystywanych certyfikatach bezpieczeństwa; • określenie kanałów komunikacyjnych (bezpieczeństwo, autentykacja, protokół transportowy); • informację o sposobie konstruowania komunikatów. • CPA (Collaboration Protocol Agreement) stanowi zasadniczo przecięcie CPP współpracujących firm, precyzujące wymagane szczegóły. • Zwykle tworzone jest przez jedną z firm i przedkładane drugiej do akceptacji. Może mieć określony okres obowiązywania. 25

26. ebXML - architektura • Interakcja partnerów biznesowych jest oparta na Schemacie Specyfikacji Procesów Biznesowych (BPSS), złożonego z: • specyfikacji procesów; • specyfikacji stosowanych dokumentów. • Obydwie specyfikacje skonstruowane są ze zdefiniowanych wcześniej komponentów podstawowych i umieszczone w rejestrze ebXML. - Głównym motywem dla takiego rozwiązania jest efektywne realizacja postulatu wielokrotnego użycia komponentów. • W tworzeniu BPSS stosuje się język UML. Powstałe modele są następnie translowane do schematów XML Schema lub DTD. • Całą zawartość rejestru określa Registry Information Model. Nie przewiduje przechowywania konkretnych dokumentów, a jedynie ich opisów (metadanych). 26

27. Modelowanie procesów biznesowych • Współpraca elektroniczna wymaga precyzyjnego opisania swoich procesów biznesowych. • Modelowanie procesów biznesowych, podobnie jak metodyki tworzenia oprogramowania stanowi samo w sobie rozległą i stosunkowo dojrzałą dziedzinę. • Pominięcie rzetelnej analizy i modelowania procesów niesie też podobne zagrożenia, jak w wypadku tworzenia oprogramowania. • Specyfikacja ebXML proponuje w tym celu metodykę UMM (Unified Modeling Methodology). 27

28. Współdziałanie biznesowe (business collaboration) • Na najniższym poziomie składa się z elementarnych kroków zwanych transakcjami biznesowymi: wiążą się one z przesłaniem dokumentu. Mogą stanowić żądania (oczekiwana odpowiedź) lub powiadomienia. Zależnie od charakteru interakcji sterowanie jest odpowiednio przekazywane pomiędzy stronami. • Typowym modelem jest współdziałanie binarne (obejmujące dwie strony); • Mogą istnieć bardziej rozbudowane – wielostronne współdziałania. • Współdziałania biznesowe posiadają swój stan oraz nałożone reguły określające, kiedy możliwe są przejścia pomiędzy stanami. 28

29. ebXML Message Service • Określa sposób wymiany komunikatów w ebXML. • Komunikaty oparte są na protokole SOAP z załącznikami. • Ciało komunikatu zawiera identyfikator przesyłanej wiadomości; • Właściwy dokument znajduje się w załączniku. • Stanowi warstwę aplikacji, odpowiedzialną za tworzenie i odczyt komunikatów ebXML, zgodnych z opisem w odpowiednim CPA. • Niezbędne dane opisowe (np. identyfikator CPA, z którym związany jest komunikat czy identyfikatory firm adresata i nadawcy) występują jako bloki nagłówkowe SOAP. • Komunikat identyfikuje odpowiedni proces biznesowy, konwersację, jak również sam przesyłany dokument. • Zawartość komunikatu może być wskazana jako odnośnik do zewnętrznego zasobu. 29

30. ebXML - podsumowanie • Specyfikacja obejmuje trzy główne części: • analiza procesów i dokumentów biznesowych; • opis sposobów współdziałania uczestniczących firm; • wymiana komunikatów. • Reprezentuje nieco inne niż w wypadku UDDI podejście do problemu dostępności usług Webu. • Posiada poparcie znaczących instytucji i firm – często zaangażowanych również w UDDI, toteż można się spodziewać że ebXML i UDDI będą współistnieć. 30

31. Architektura Web Services - Podsumowanie • Usługa Webu jest abstrakcyjnym zbiorem funkcjonalności, implementowanym przez konkretnego agenta (element oprogramowania zdolny wysyłać i przyjmować komunikaty). • Istnieje wobec tego szeroki zakres różnorodności i zmienności agentów, realizujących taką samą nie zmienioną usługę (co realizuje postulat luźnego skojarzenia).Niezależnie od scenariusza, uzgodnienie semantyki usługi pośrednio lub bezpośrednio należy do ludzi z inicjatywy których działają agent żądający usługi oraz agent dostawca. • Poza ograniczeniami nakładanymi na postać i sposób wymiany komunikatów warto jeszcze raz podkreślić, że koncepcja Web Services obejmuje również działania wykraczające poza wymianę informacji – tj. różnego rodzaju czynności i zdarzenia w świecie materialnym będące skutkiem wykonania usługi. 31

32. Architektura Zorientowana na Usługi (SOA) • Usługi Webu stanowią wystąpienie tzw. Service Oriented Architecture (SOA). SOA zaś jest szczególnym rodzajem systemu rozproszonego, toteż musi uwzględniać typowe dla takich systemów problemy, jak mniejsza niezawodność oraz opóźnienia komunikacyjne. • SOA zakłada, że wyodrębnione jej ramach usługi mogą być wywoływane niezależnie od kontekstu większej aplikacji i posiadają adresowalne w sieci interfejsy stosujące standardowe protokoły i formaty danych. Ponadto publiczna architektura SOA wymaga istnienia opisu usług i wymienianych w ramach nich komunikatów. • W ten sposób również same takie opisy stają się przedmiotem wymiany i udostępniania w tej architekturze. • Dodatkowo, środowisko Webu precyzuje następujące ograniczenia: • zasoby dostępne agentom są identyfikowane poprzez URI; • zasoby posiadają reprezentację w jednym z szeroko stosowanych formatów. 32

33. Fundamenty technologii Web Services • W istocie do roli najbardziej nieodłącznego składnika usług Webu pretenduje XML. Jest obecny w niemal wszystkich używanych tam technologiach. Bardziej adekwatne byłoby zatem uwidocznienie XML i XML Schema jako „tła” niż jako dolnej warstwy stosu protokołów. • Z założenia architektura usług Webu nie umieszcza się jako konkretna warstwa np. w modelu OSI. Zamiast tego zakłada niezależność i możliwość wykorzystania różnych protokołów zbudowanych w innych celach jako nośników komunikatów. • Wyróżnikiem architektury Web Services jest jej oparcie na „przejrzystym” protokole, umożliwiającym zweryfikowanie zawartości komunikatu – np. przez wspierające XML i jego protokoły zapory ogniowe. • Protokół SOAP, jakkolwiek nie jest niezbędny dla zrealizowania wymiany komunikatów, stwarza niezbędną standardową podstawę dla realizacji takich zadań jak ochrona danych, autentykacja, kodowanie, kontrola dostępu czy transakcje. 33