PROBLEMY WSPÓŁCZESNEJ SERVICE ORIENTED ARCHITECTURE

Transkrypt

1 PROBLEMY WSPÓŁCZESNEJ SERVICE ORIENTED ARCHITECTURE KATARZYNA LANGE-SADZI SKA Uniwersytet Łódzki MAŁGORZATA ZIEMECKA Uniwersytet Łódzki, Wy sza Szkoła Informatyki w Łodzi Streszczenie W artykule zawarto informacje na temat SOA. Zaprezentowano problemy zwi zane z wdro eniem i u ytkowaniem współczesnej architektury SOA. Słowa kluczowe: SOA, Architektura zorientowana na usługi, Web Services 1. Wprowadzenie Niejedno przedsi biorstwo staje przed problemem wykorzystywania aplikacji ró nych producentów i konieczno ci ich integracji. Taka integracja jest trudna, poniewa praktycznie nie istnieje komunikacja mi dzy tymi aplikacjami, co oznacza kłopoty z wymian danych mi dzy nimi. Cz sto nie udaje si zrealizowa jej automatycznie, zatem przeprowadzenie jej z sukcesem wymaga du ego nakładu czasu i mocy obliczeniowej. Nie zawsze dobrym pomysłem w tej sytuacji jest zamiana istniej cych aplikacji na inne, szczególnie wtedy, gdy obecnie wykorzystywane dobrze spełniaj zadania, do których zostały stworzone. Wymiana oprogramowania wi załaby si ponadto z wymian sprz tu, szkoleniami dla pracowników i generowałaby dodatkowe koszty. Metod, która w tej sytuacji pozwoliłaby zachowa oprogramowanie i sprz t jest SOA (Service Oriented Architecture). 2. Definicja SOA SOA oznacza architektur nastawion na usługi lub opart na usługach.[4] Mo na równie powiedzie, e jest to zestaw postulatów, rekomendacji i dobrych praktyk zwi zanych z projektowaniem architektury systemów informatycznych. [4] Architektur nale y rozumie jako logiczn struktur systemu lub systemów informatycznych z wyodr bnionymi głównymi elementami składowymi i powi zaniami mi dzy nimi. W przypadku architektury zorientowanej na usługi, logika powi za ma by zbudowana w postaci lu no powi zanych usług. Usługa jest to dowolny fragment funkcjonalno ci przydatny dla u ytkownika. Jedn z charakterystycznych cech SOA jest dzielenie procesów na mniejsze jednostki, które zebrane razem tworz wi kszy element usprawniaj cy biznes, ale osobno mog by przeznaczone do wykonywania ró nych, zupełnie innych prac. Jednostki odpowiadaj zbiorowi zasad, które pozwalaj im na samodzielny rozwój, a jednocze nie daj odpowiedni poziom standaryzacji. Te jednostki w SOA s wła nie usługami. Model rzeczywisto ci zorientowanej usługowo pozwala przygl da si ogólnej istocie problemu i nie zajmowa si szczegółami dotycz cymi np. programowania. Ten sposób postrzegania umo liwia takie pode cie do problemu, aby zauwa y najwa niejsze jego aspekty przy jednoczesnym pomini ciu szczegółów.[1]

2 Katarzyna Lange-Sadzi ska, Małgorzata Ziemecka Problemy współczesnej Service Oriented Architecture 41 SOA praktycznie rozwi zuje poł czenie sfer IT i biznesowej w firmie. Metoda ta mo e zrewolucjonizowa stosunki mi dzy tymi sferami, je li tylko uda si zmieni pogl dy o tworzeniu, wdra aniu i zarz dzaniu oprogramowaniem i zaimplementowa SOA. SOA jest podej ciem do architektury, polegaj cym na rozło eniu zło onych operacji na proste funkcje biznesowe, do wielokrotnego wykorzystania przez wiele procesów. SOA mo na stosowa na trzy sposoby: jako nowe podej cie do problemów integracyjnych 1 ; aby ci lej zwi za IT z celami biznesowymi firmy; jako model do prezentowania oprogramowania. Zastosowanie SOA powinno umo liwi zmniejszenie kosztów integracji rodowiska IT, lepsze wykorzystanie zasobów IT, minimalizacj ryzyka operacyjnego i biznesowego oraz zwi kszenie sprawno ci prowadzenia biznesu.[7] 3. Wdra anie SOA Do wdra ania architektury zorientowanej na usługi nale y si odpowiednio przygotowa. Przyjmuje si, e nale y je rozpocz od rozeznania w najwa niejszych zasobach firmy: ludziach, informacji i procesach. Wa ne jest, aby wszyscy mieli wiadomo, w jaki sposób cała organizacja i poszczególne jej działy b d przechodziły od tradycyjnej architektury IT w stron SOA. [6] Firmy, które zdecyduj si na wdro enie SOA, co oznacza b dzie zmian kultury organizacyjnej, powinny wzi po uwag nowe problemy. Implementacja SOA powoduje pojawienie si w przedsi biorstwie nowych technologii, nowych procesów, nowego sposobu my lenia. Oprócz szkole technicznych nale y koncentrowa si na wprowadzaniu umiej tno ci zaimplementowania nowych procesów biznesowych. Technologia to nie wszystko. [6] Proces wdra ania SOA wymaga czasu i wielkiego wysiłku firmy. W zale no ci od potrzeb, elementy SOA b d wdra ane w ró nym zakresie. Mo e powsta wi c architektura hybrydowa, ł cz ca star, rozproszon i now, zorientowan na usługi. Ponadto przedsi biorstwa b d musiały przystosowywa swoje rodowiska do zmian, poniewa zmienia si b d zwi zane z SOA standardy i protokoły. B d dojrzewa i ewoluowa. 4. Bł dy implementacji SOA Wiele firm osi gn ło pozytywne rezultaty wynikaj ce z wdro enia SOA. Jednak s i takie, które nie widz adnych korzy ci z implementacji architektury zorientowanej na usługi. Mogło si zdarzy, e nieprawidłowo rozpocz ły implementacj. Bardzo cz sto bł dy popełnione na starcie spowoduj nieudane wdro enie. Kolejnym wa nym zagadnieniem przy wdra aniu SOA jest wyposa enie jej w standardy. Przy zało eniu tworzenia w firmie wielu projektów, w tym jednego, odizolowanego, z architektur zorientowan usługowo mo e si okaza, e finalny produkt nie b dzie dostosowany do innych projektów. Wynika to z tworzenia aplikacji, które maj ró ne opisy usług czy charakterystyki. W przypadku SOA, jak i wielu innych architektur, bardzo wa ne jest opracowanie planu przej cia. W przeciwnym przypadku mo e si okaza, e przechodzenie na architektur zorien- 1 Np. przy wykorzystaniu tzw. szyny usługowej ESB (Enterprise Service Bus), która jest zestawem produktów umo liwiaj cych ł czenie składowych infrastruktury IT.

3 42 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 29, 2010 towan na usługi spowoduje powa ne problemy. Wdra anie zawsze niesie ze sob zmiany w funkcjonowaniu całego przedsi biorstwa. Powinna by zatem przeprowadzona analiza wpływu tych zmian na wszystkie sfery działania przedsi biorstwa (mi dzy innymi na zasoby, procesy i technologi ). Oczywi cie nale ałoby w miar mo liwo ci zainteresowa si przyszło ci usług sieciowych i technologii z nimi zwi zanych. Modelowanie SOA przebiega nieco inaczej ni przy podobnych projektach i polega na odwzorowaniu rzeczywistego wiata w taki sposób, aby rzuci wiatło na relacje i współdziałanie usług w rodowisku wielozadaniowym. Cz sto tworzone jest odwzorowanie architektury przedsi biorstwa w celu testowania wybranego oprogramowania. W ten sposób mo na wyeliminowa ju na pocz tku wiele bł dów. U podstaw współczesnej SOA le y technologia XML. Z tych podstaw wykształciły si inne technologie i standardy, bardzo wa ne dla funkcjonowania SOA. Du ym problemem w implementacji SOA jest współpraca mi dzy lud mi, a wła ciwie jej brak. Udane wdro enie SOA wymaga współdziałania ró nych działów firmy, poniewa projekty i wdro enia b d si wzajemnie przenikały i nie b d traktowały poszczególnych działów jak osobnych wysp. Implementacja zało e architektury zorientowanej na usługi b dzie wymagała np. bliskiej współpracy działów biznesu i działu IT w firmie. Bardzo cz sto trzeba przełamywa niech do takiej współpracy i do zmiany starych nawyków. Problemem, który musi rozwi za ka de wdra aj ce przedsi biorstwo jest konieczno zapewnienia rodków na szkolenia pracowników. Pracownicy zwi zani z wdro eniem i u ytkownicy ko cowi musz wykaza gotowo do odbycia szkole. Pracownicy musz by wiadomi zmian, jakie ich czekaj oraz wagi ich pomocy przy implementacji. 5. Współczesna SOA Współczesna SOA została stworzona na podstawie podstawowego modelu, przy wykorzystaniu udoskonale technologicznych. Jest wiele kategorii, które wyró niaj współczesn SOA spo ród innych koncepcji. Architektura zorientowana na usługi jest u ywana jako okre lenie wszystkich platform aplikacyjnych, zawieraj cych technologi Web Services 2 i bazuj cych na orientacji usługowej. Obecnie d y si do podniesienia jako ci usług, czyli mo liwo ci bezpiecznej i niezawodnej implementacji jak w przypadku innych, dłu ej wykorzystywanych modeli. Bardzo wa n, a mo e najwa niejsz charakterystyk SOA jest to, e przekazywanie danych jest zarz dzane przez otwarte standardy. Przesyłanie wiadomo ci mi dzy usługami odbywa si poprzez zestaw ogólnie akceptowalnych protokołów. Równie format i sposób prezentacji wiadomo ci jest standaryzowany. Współczesna SOA wspiera otwarte standardy w komunikacji i czyni mo liw komunikacj mi dzy ró nymi usługami. Wspomniana otwarto oznacza, e przedsi biorstwa maj wybór spo ród wielu rozwi za na rynku i mog korzysta z wi kszej ilo ci narz dzi ni do tej pory. Jednocze nie nie oznacza to konieczno ci rezygnacji z posiadanych platform, ale daje szanse na korzystanie z wi kszej ilo ci narz dzi ni dotychczas. Architektura zorientowana na usługi wspiera wyszukiwanie istniej cych usług zarówno wewn trz przedsi biorstwa, jak i na zewn trz. SOA pozwala współdziała aplikacjom, które nie mogły tego wcze niej robi, daj c mo liwo zamykania aplikacji w usługach dzi ki u yciu otwartych standardów. Architektura SOA d y do wykorzystania zasobów na wielu poziomach. Przejawia si to 2 Opis w punkcie 7.

4 Katarzyna Lange-Sadzi ska, Małgorzata Ziemecka Problemy współczesnej Service Oriented Architecture 43 m.in. w nacisku na to, eby efektem ubocznym ko czonych projektów były usługi, które b d u yteczne w przyszło ci. Jedn z cech charakterystycznych SOA s tzw. lu ne ł czenia mi dzy usługami. Usługi s niezale ne i do działania potrzebuj jedynie wiedzy o innych usługach. Pozwala to na uzyskanie lu nych ł cze mi dzy dziedzinami biznesu a aplikacjami firmy, a w rezultacie mo liwo osobnej ewolucji ka dej dziedziny. Dla przedsi biorstwa przechodz cego reorganizacj wewn trzn, poł czenie z innym przedsi biorstwem lub jakiekolwiek zmiany organizacyjne i technologiczne, wa na jest umiej tno przystosowania si do tych zmian i reagowania na zwi zane z nimi wydarzenia. Dzi ki rozwi zaniom dostarczanym przez architektur zorientowan na usługi, mo na zwi kszy sprawno organizacyjn, co uwa ane jest za jedn z najwi kszych korzy ci uzyskanych dzi ki SOA. W ród innych korzy ci z zastosowania architektury zorientowanej na usługi wymienia si krótszy czas reakcji na zmiany oraz wykorzystanie otwartych standardów komunikacyjnych. 6. Web Services Z SOA kojarz si najcz ciej standardy definiuj ce Web Services 3 czyli usługi sieciowe. Usługi Web Services umo liwiaj aplikacjom wymienianie si danymi oraz co jeszcze istotniejsze wykorzystywanie mo liwo ci innych aplikacji, niezale nie od tego, jak zostały zbudowane, w jakim systemie operacyjnym działaj oraz za pomoc jakich urz dze uzyskuje si do nich dost p. Mimo, e usługi Web Services działaj niezale nie od siebie, mog ł czy si w lu ne konfiguracje usług, które wykonuj okre lone zadania.[10] Web Services dobrze nadaj si do realizacji SOA. Wspomniane standardy pozwalaj na udost pnienie funkcjonalno ci systemów w postaci usług o zdefiniowanym interfejsie, niezale nym od rodowiska i technologii, w której dana funkcjonalno jest zaimplementowana. [4] Web Services opieraj si na szeroko akceptowanych na rynku informatycznym specyfikacjach, opracowanych przez konsorcjum W3C. Do zdefiniowania usług dost pnych jako Web Services słu y WSDL (Web-Services Descripion Language), czyli opracowany przez Microsoft i IBM, oparty na XML4 j zyk do definiowania usług sieciowych. Powstało te wiele innych standardów do wspierania budowy wszelkich rozwi za opartych o Web Services. Nale do nich: UDDI (Universal Description, Discovery and Integration), który pozwala na wyszukiwanie informacji o dost pnych usługach sieciowych i SOAP (Simple Object Access Protocol) do zdalnego wywoływania usług. Z wykorzystaniem usług sieciowych wi si takie aspekty jak bezpiecze stwo, transakcyjno, obsługa zdarze. Do wsparcia stosuje si standardy oparte na XML. Technologia Web Services mo e by podstaw do realizacji architektury zgodnej z SOA. Jednak e podej cie SOA mo na zrealizowa korzystaj c niemal z dowolnej technologii, a nawet w rodowiskach heterogenicznych, korzystaj c z wielu ró nych technologii. SOA nie wymaga konkretnych technologii, a nawet pozwala wykorzystywa istniej ce, sprawdzone technologie i funkcjonalno ci istniej cych systemów. Konieczne jest tylko dopisanie interfejsu usługowego, dost pnego dla wszystkich zainteresowanych konsumentów usług. Wa ne jest, aby organizacja wiedziała, jak definiowa Web Services i jak je tworzy. Ponad- 3 Komponent programowy niezale ny od platformy i implementacji, dostarczaj cy okre lonej funkcjonalno ci. 4 XML (Extensible Markup Language) - uniwersalny j zyk formalny przeznaczony do reprezentowania ró nych danych w strukturalizowany sposób.

5 44 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 29, 2010 to u ywanie Web Services niesie ze sob niebezpiecze stwa zwi zane z udost pnianiem Web Services na zewn trz lub u ytkowaniem Web Services udost pnianych przez innych. [5]. 7. Korzy ci z SOA Architektura zorientowana usługowo daje szans na korzystanie z usług wielofunkcyjnych. Wielofunkcyjno pozwala na łatwiejsz integracj wielu platform, uwzgl dnienie wzajemnych relacji mi dzy procesami przedsi biorstwa a procesami jego partnerów. U podstaw budowy i zarz dzania SOA le dane dostarczane w formacie XML. Daje to szans i jednocze nie konieczno pełnego wykorzystania platformy XML i uzyskania wysokiego stopnia standaryzacji. SOA mo e dokona centralizacji komunikacji mi dzy aplikacjami oraz wewn trz nich. Pozwoli to inwestowa w jedn technologi komunikacyjn i w ten sposób zmniejszy nakłady na infrastruktur telekomunikacyjn. SOA zwi ksza mo liwo ci biznesu i IT. Architektura zorientowana na usługi wspiera najlepsz w danej sytuacji technologi i pozwala zwi kszy zasi g i jako przyj tych do realizacji celów. Sprawno organizacyjna jest zwi zana z ka dym aspektem działania firmy. Budowanie wszelkich elementów, takich jak algorytmy, procesy, cz ci oprogramowania w ramach istniej cych ogranicze okre la sprawno organizacji jako cało ci. Architektury zorientowane usługowo maj w zło eniu stworzenie takich produktów, które dzi ki ponownemu zastosowaniu i wielozadaniowo ci b d mogły si rozwija. Podstawowe zyski płyn ze zmniejszenia kosztów tworzenia i wdra ania nowego oprogramowania. Wynikaj one z szybko ci realizacji nowych pomysłów i ulepsze ju istniej cych. Przygotowanie ulepsze i poprawek mo e trwa do 40% szybciej i za 75% rodków [11] w porównaniu z wcze niejszym stanem. Wynika to z ze skrócenia całego procesu od projektowania, poprzez budow i faz testu. Proces ten mo e bowiem u ywa gotowych, wykonanych wcze niej komponentów. Ponadto testowanie dotyczy tylko nowo stworzonych usług, co wydatnie skraca jego czas. Po wdro eniu SOA kolejne systemy b d wdra ane szybciej. Łatwiejsze b dzie wprowadzanie zmian w systemach. Firma uniezale ni si od monopolu dostawców kluczowych systemów. Upro ci si wdra anie nowych procesów biznesowych, które b d mogły opiera si na usługach platformy SOA. Z bada Aberdeen Group [11] wynika, e dwa tysi ce najwi kszych przedsi biorstw na wiecie, zaanga owanych w implementacj SOA odnotuje do 2014 roku oszcz dno ci w wysoko ci 53 miliardów dolarów. To oznacza, e firma o bud ecie IT w wysoko ci 200 milionów dolarów mo e zaoszcz dzi nawet 20 milionów dolarów po pi cioletnim okresie wdro eniowym SOA.

6 Katarzyna Lange-Sadzi ska, Małgorzata Ziemecka Problemy współczesnej Service Oriented Architecture Wady SOA Korzystanie z SOA niesie liczne zagro enia. Mówi si o niskim poziomie zabezpiecze architektury zorientowanej na usługi. Decentralizacja zabezpiecze utrudnia kontrol nad nimi. System zabezpiecze jest mało skomplikowany i podzielony mi dzy usługi. Jest to jedno z trudniejszych zada do rozwi zania stoj cych przed specjalistami. Wad SOA jest to, e przed jej zaimplementowaniem trudno jest wskaza płyn ce z niej korzy ci. Dopiero po pewnym czasie wida zalety tego posuni cia. Dlatego stosuje si zabieg polegaj cy na zastosowaniu architektury zorientowanej na usługi w małym fragmencie przedsi biorstwa, aby przekona kierownictwo do wdro enia w całej firmie. Jednocze nie b dzie mo na wychwyci podstawowe bł dy, które pojawi si na tym etapie.[2] Kolejnym problemem jest ponowne u ycie usług. Usługi cz sto tworzy si na konkretne potrzeby. Je li zostan wykorzystane w innych procesach, do których ich nie zaprojektowano to mog spowodowa powstanie problemów, ł cznie z oddziaływaniem na całe przedsi biorstwo. Problemem jest z reguły brak odpowiedniej kadry, dzi ki której mo na poprowadzi wdro enie. Przedsi biorstwo jest wtedy zmuszone do zatrudnienia zewn trznych konsultantów lub stałego outsourcingu. Przedsi biorstwo nie mo e korzysta z wiedzy swoich pracowników, ale jednocze- nie uzyskuje pomoc specjalistów, których do wiadczenie pozwoli zredukowa koszty ostatecznego rozwi zania. Oczywi cie mo na te szkoli pracowników, aby mie przynajmniej kilku specjalistów na miejscu. Wybór odpowiedniej drogi powinien by podyktowany do wiadczeniami firmy przy dotychczasowych wdro eniach.[2] Problemy zwi zane z SOA dotycz jednej z jej po danych cech elastyczno ci. Wzrost elastyczno ci powoduje zmniejszenie kontroli. Czy zatem wa niejsze s zyski z wi kszej elastyczno- ci, czy kłopoty spowodowane zmniejszeniem kontroli? Wi kszo zainteresowanych twierdzi, e wa niejsze s korzy ci z elastyczno ci. S zreszt metody na rozwi zanie problemów z kontrol. Najprostsza polega na tym, aby w procesach, w których kontrola jest szczególnie wymagana, stosowa tylko te elementy, które łatwo skontrolowa. SOA niesie te przedsi biorstwom problemy, które wynikaj z jej niedostatków i zmusza poszczególne przedsi biorstwa do ich rozwi zywania. Istniej szanse, e ewolucja SOA pozwoli na globalne wyeliminowanie tych problemów w przyszło ci.[2] 9. Bezpiecze stwo SOA Zapewnienie bezpiecze stwa transakcji realizowanych za po rednictwem architektury SOA, w ramach której budowane s aplikacje dynamiczne jest procesem zło onym. W jego ramach realizowana jest ochrona infrastruktury SOA przed atakami oraz monitorowanie korzystania z uług. Polityka bezpiecze stwa powinna by elementem polityki biznesowej, okre laj c zakazy i nakazy słu ce bezpiecznemu korzystaniu z systemu. W jej ramach ustala si mi dzy innymi sposób autoryzacji i mechanizmy kontroli dost pu, specyfikuje metody uwierzytelniania oraz okre la wymagania poufno ci i integralno ci. Do podstawowych zagro e SOA zaliczy nale y zagro enia zwi zane z zawarto ci takie jak ataki SQL Injection, Capture/Replay, XPath Injection czy zał czniki SOAP. Atak SQL Injection polega na wprowadzeniu instrukcji SQL do danych XML, dzi ki którym wydobywane s zastrze one dane lub generowany jest bł d pozwalaj cy na ujawnienie informacji

7 46 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 29, 2010 zwi zanych z dost pem do bazy danych. Ten rodzaj ataku przeprowadzany jest na systemy generuj ce zapytania do bazy danych i wykorzystuje luki w zabezpieczeniach zwi zane z nieodpowiednim filtrowaniem i pó niejszym wykonaniem danych przesyłanych w postaci zapyta SQL do bazy danych. Jest skuteczny wtedy, gdy dane odbierane przez usług w SOA s zamieszczone bezpo rednio w wyra eniu SQL, które jest uruchamiane z uprawnieniami dostatecznymi do wykonania ataku. Atak Capture/Replay jest procesem, w którym napastnik najpierw przechwytuje odpowiedni strumie danych, a nast pnie odtwarza go dla osi gni cia okre lonego efektu. Wykorzystuje on luki w schemacie uwierzytelnienia atakowanego systemu. Zastosowanie znaczników czasowych, z ustalonym optymalnie czasem wa no ci, pozwala na przeciwdziałanie takim atakom, poniewa komunikat odtworzony zawiera b dzie nieaktualny znacznik czasowy. Atak XPath Injection wykorzystuje dane wprowadzane przez u ytkownika do konstrukcji kwerendy XPath umo liwiaj c wyprowadzenie informacji z baz danych XML. Przeciwdziałanie takim atakom polega na wprowadzeniu kontroli sprawdzaj cej, czy dane przekazywane do wyra- enia XPath same nie zawieraj XPath. Zał czniki SOAP mog by gro ne wtedy, gdy zawieraj wirusy, s zbyt du e lub trudne do przetwarzania. Przeciwdziałanie tym problemom polega na blokowaniu zał czników, ich filtrowaniu na podstawie typu MIME lub skanowaniu programem antywirusowym. Monitorowanie korzystania z usług pozwala na ustalenie u ytkownika, dzi ki czemu mo na kontrolowa dost p do usługi oraz ustali na potrzeby audytu wykonywane przez niego czynno ci. Kontrola dost pu do usługi wymaga zastosowania ró nych standardów takich jak certyfikaty X.509, XML Encryption, WS-Security czy bramy XML. Certyfikaty X.509 s wykorzystywane w kontek cie uwierzytelniania SSL pozwalaj c weryfikowa to samo Web services przez stron klienck lub klienta przez Web services. XML Encryption jest standardem definiuj cym sposób szyfrowania danych XML, przy czym dane mog by szyfrowane selektywnie Standard WS-Security definiuje sposób szyfrowania i podpisania wiadomo ci SOA z wykorzystaniem XML Encryption i XML Signature. Okre la tak e posób umieszczenia hasła i certyfikatu X.509 w wiadomo ci SOAP oraz współdziałania SOAP z Kerberos. Bramy XML, dzi ki stosowaniu reguł polityki bezpiecze stwa do usług realizowanych w chronionym rodowisko SOA, udost pniaj bezpieczne przetwarzanie w sieci z wykorzystaniem akceleratorów sprz towych. Zapewniaj one cz sto tak e po rednictwo mi dzy protokołami, transformacje i przyspieszenie. [3]. 10. Podsumowanie Bardzo wa n korzy ci z wdro enia architektury zorientowanej na usługi jest zredukowanie kosztów utrzymania infrastruktury IT. Jeszcze wi ksz jest uzyskanie elastyczno ci działania, zdolno ci szybkiego reagowania na zmiany rynkowe i wymagania klientów. Wa na jest tu cisła współpraca z biznesem, która pozwoli wykorzysta zwi zane z wdro eniem SOA korzy ci. Elastyczno IT i biznesu ma ogromne znaczenie w utrzymaniu oraz zwi kszaniu warto ci firmy. Nowa architektura IT i biznesu pozwoli osi gn przewag nad innymi, mi dzy innymi pomagaj c szybciej dostosowa si do zmian w otoczeniu biznesowym. SOA jest przez wielu specjalistów uwa ana za nowy, nast pny standard do tworzenia systemów informatycznych. Jako młode podej cie, posiada jeszcze wiele wad i niedoci gni, które

8 Katarzyna Lange-Sadzi ska, Małgorzata Ziemecka Problemy współczesnej Service Oriented Architecture 47 b d rozwi zywane. Architektura zorientowana na usługi umo liwia poł czenie działa informatyki i biznesu, do czego d ono ju wcze niej, jednak bez wi kszego powodzenia. Ju na samym pocz tku wdra ania pracownicy wszystkich działów musz ze sob współpracowa, aby pokona wszelkie trudno- ci wdro enia i ta współpraca musi by utrzymana. SOA mo e da szans przedsi biorstwu na osi gni cie jednolitej struktury, szybsze przygotowywanie rozwi za i obni enie nakładów. Wymaga jednak przemy lanych działa, stosowania si do przyj tego planu i dokonywanie ewentualnych poprawek, je li b dzie to konieczne. Architektura zorientowana na usługi, która jest w stanie ł czy działaj ce niezale nie od siebie systemy, spotyka si z szerokim zainteresowaniem. Idea, która pozwala ł czy w cało i zapanowa nad t cało ci okazuje si obecnie bardzo potrzebna i poszukiwana. W tym kontek- cie wida, e SOA ma szans sta si nowym standardem w tworzeniu rodowisk informatycznych. Jeszcze pozostało do rozwi zania wiele problemów, ale wyniki pierwszych ankiet przeprowadzonych w ród przedsi biorstw wdra aj cych SOA s bardzo obiecuj ce, co pozwola sadzi, e nast pi rozwój i dojrzewanie architektury zorientowanej na usługi.[2] Jak uzyska pewno, e inicjatywa implementacji architektury SOA przynosi firmie maksimum mo liwych korzy ci? Aby siła architektury zorientowanej na usługi została faktycznie w pełni wykorzystana, architektura ta musi by nie tylko oparta na solidnym, sprawdzonym wzorcu strukturalnym, lecz tak e przynosi firmie jak najwi ksz warto biznesow ju od pocz tkowego etapu wdro enia. Warto zatem zdefiniowa projekty o znacz cym wpływie na działalno organizacji, które zaspokaja jej potrzeby ju w krótszej perspektywie czasowej i sprawi, e rodowisko informatyczne b dzie nieustannie stymulowa innowacyjne zmiany w modelu biznesowym.[12] Implementacja SOA nie jest zadaniem łatwym. Szczególnie trudna jest w organizacjach, które nie s z ró nych wzgl dów przygotowane do gł bokich zmian w sposobie my lenia o biznesie, o roli IT w kreowaniu warto ci firm, które s odporne na zmiany. [6] Obiecuj ce s do wiadcznia z wdro e SOA w polskich firmach. W kwietniu 2008 Business Dialog i CIO Business Meeting Point wspólnie z firm IDS Scheer Polska przeprowadziły badanie "Architektura IT dla wymagaj cego biznesu". Autorzy chcieli dowiedzie si od szefów działów i samodzielnych analityków IT, jakiego przygotowania wymaga polska firma, aby wdro enie architektury IT opartej na usługach SOA miało sens biznesowy i szanse powodzenia. Okazało si, e wdro enia osi gn ły wysoki poziom 36% firm bior cych udział w badaniu o wiadczyło, e jest w trakcie realizacji projektu SOA; 26% ju taki projekt zrealizowało; 20% planuje realizacj w ci gu najbli szych kilku lat. [9]. Po wdro eniu cz sto okazuje si, e u ytkowanie SOA nie jest proste i potrzebny byłby zespół w ramach działu IT, który zajmowałby si utrzymaniem i wsparciem architektury zorientowanej usługowo. Niestety w polskich warunkach niewiele przedsi biorstw mo e sobie na to pozwoli. Szacuje si, e obecnie najwy ej 50. [9]

9 48 POLSKIE STOWARZYSZENIE ZARZ DZANIA WIEDZ Seria: Studia i Materiały, nr 29, 2010 Tabela 1. Najwa niejsze przesłanki do zastosowania architektury IT zorientowanej na usługi w polskich warunkach Potrzeba przyspieszenia tempa wspierania przez IT nowych produktów, nowych kanałów 64% sprzeda y Ch obni enia kosztów przyszłych wdro e 60% Nasilenie zmian i usprawnie organizacyjnych w procesach, które wymagaj obsługi IT, 52% konieczno zwi kszenia elastyczno ci działania Potrzeba integracji pomi dzy istniej cymi ju systemami IT a nowo wprowadzanymi 40% Potrzeba integracji ró nych systemów korporacyjnych 36% Konieczno usprawnienia zarz dzania informatyk, aby dział IT wywi zywał si z wi kszej 16% liczby zada w szybszym tempie, ale bez zwi kszania kadr i nakładów na IT Potrzeba integracji w czasie rzeczywistym z partnerami biznesowymi i ich systemami IT 12% Wzrost kosztów utrzymania dotychczasowej, starzej cej si architektury IT 8% Fuzja z inna firm 4% Potrzeba integracji z aplikacjami w centrali mi dzynarodowej firmy 0% ródło: [9] Bibliografia [1] Bell M. Service-Oriented Modeling. Service Analysys, Design, and Architecture, Haboken New Jersey, USA 2008, s. 56. [2] Kuchowicz M., Service-Oriented Architecture jako nowoczesna koncepcja projektowania systemów informatycznych, Łód 2009, s.17 26, [3] Muszy ski J., Podstawy bezpiecze stwa SOA, NetWorld, 13 lipca [4] P kała P., Kiedy si sprawdza? [w:] ComputerWorld, Tygodnik mened erów i informatyków, Warszawa, , s [5] Rosen M., Lublinsky B., Smith K.T., Balcer, M. J., Applied SOA: Service-Oriented Architecture and Design Strategies, Implementing SOA: Total Architecture in Practice, Boulevard Indianapolis, USA [6] Skrupski K., Człowiek do zada specjalnych [w:] ComputerWorld, Tygodnik mened erów i informatyków, Warszawa, , s [7] Teleinfo, Pismo profesjonalnych u ytkowników informatyki i telekomunikacji, s. 23. [8] [9] [10] [11] [12]

10 Katarzyna Lange-Sadzi ska, Małgorzata Ziemecka Problemy współczesnej Service Oriented Architecture 49 PROBLEMS OF CONTEMPORARY SERVICE ORIANTED ARCHITECTURE Summary In the article there is a piece of information on SOA. There also presented some problems connected with the introduction and using of current SOA. Keywords: SOA, service oriented architecture, Web Services Katarzyna Lange-Sadzi ska Małgorzata Ziemecka Katedra Informatyki Ekonomicznej Wydział Ekonomiczno-Socjologiczny Uniwersytet Łódzki ul. Polskiej Organizacji Wojskowej 3/5, Łód klange@uni.lodz.pl, mlziem@uni.lodz.pl