soastandard.pl - architektura zorientowana na usługi - link do strony głównej
wyszukiwanie:
Podziel się opinią o serwisie

reklama

Wizjonerski system ERP

Strefa EpicorDowiedz się dlaczego Gartner wymienia naszą firmę w gronie wizjonerów. Zobacz prezentację Epicor 9 i poznaj korzyści jakie daje architektura SOA.
Zapraszamy do strefy »

WHITEPAPERS

IBM

SOA dla biznesu

Efektywna integracja przedsiębiorstwa w oparciu o SOA i rozwiązania IBM WebSphere. Co i jak - same konkrety.

Raport przygotowany przez Computerworld przy współpracy IBM.

Sybase

Architektura korporacyjna i SOA

W biznesie chodzi o biznes, nie informatykę. Jak wdrażać nowe strategie, cele i pomysły bez konieczności długotrwałej i kosztownej przebudowy systemów IT? Zobacz jak te zadania może ułatwić budowa środowiska informatycznego w modelu SOA. Pobierz bezpłatny raport przygotowany przez Computerworld i Sybase.

SOAstandard

SOA, czyli IT do usług

Każdy kto zajmuje się zarządzaniem IT, zwłaszcza w dużych organizacjach, wie co to jest SOA. Te trzy literki to obietnica systemów informatycznych, które "wszystko mogą", aplikacji biznesowych "nie mających ograniczeń", rozwiązań które w "ekspresowym tempie" można przystosować do bieżących potrzeb biznesowych.

popularne komentowane nowości

popularne

Najczęściej czytane

powiększ tekst >
ARCHIWUM

Człowiek do zadań specjalnych

23 czerwca 2009

Krzysztof Skrupski
(Strona 2 z 4)

Computerworld — Ważne jest, aby dyrektor IT rozumiał, jak zmieni się model działania IT oraz całej organizacji w momencie wdrożenia SOA. 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. W jaki sposób będą konsumowały serwisy, zarówno te, dostarczone wewnętrznie, jak i przez firmy trzecie, na przykład przez partnerów biznesowych.

Bardzo istotne jest też zrozumienie, że narzędzia i technologie samodzielnie nie są w stanie dostarczyć korzyści z SOA - procesy biznesowe, umiejętności oraz podejście są dużo ważniejsze! Na przykład, jeśli wdrożenie SOA ma zakończyć się sukcesem, świadomy dyrektor IT musi wdrożyć politykę i procedury służące kontrolowaniu środowiska SOA natychmiast po przejściu etapu "proof of concept". Rozwijając to zagadnienie, możemy podzielić te procesy kontrolne na trzy grupy: SOA Governance, SOA Service Management oraz Service Quality.
SOA Governance

O ile wiele organizacji używa dzisiaj serwisów, o tyle niewiele z nich używa najlepszych metod i doświadczeń (Best practices) do zarządzania nimi. To ewidentna pomyłka - duża część korzyści z wdrożenia SOA wynika z ponownego użycia serwisów i używania otwartych standardów, a to nie będzie możliwe bez zdefiniowanych i przestrzeganych procedur i polityk.

SOA Governance jest definicją i implementacją w organizacji polityk dla następujących działań:
- tworzenie nowych serwisów
- zmiana istniejących serwisów
- usuwanie serwisów na końcu ich cyklu życia
- udostępnianie serwisów firmom trzecim
- publikowanie i wyszukiwanie serwisów
- ponowne użycie serwisów
- monitorowanie SOA
- określanie wartości wnoszonej przez SOA
Jeżeli procesy odpowiadające za te działania nie są znane od samego początku, indywidualne projekty w sposób nieuchronny będą dążyły do wytwarzania serwisów, które nie będą zdolne do współpracy z innymi serwisami. Użycie i zarządzanie takimi serwisami jest bardzo trudne, w skrajnych przypadkach nawet niemożliwe! W efekcie środki wydane na implementację SOA są zmarnowane: ponieważ serwisy nie będą użyte ponownie, zwiększa się koszty przyszłych projektów. To pokazuje, w jaki sposób aplikacje budowane przy użyciu SOA mogą być droższe od tradycyjnych aplikacji.

Jednym z najtrudniejszych aspektów SOA Governance jest proces eskalacji oraz definiowanie i egzekwowanie obszarów odpowiedzialności. W tradycyjnej, scentralizowanej architekturze IT bardzo łatwo jest ustalić obszary odpowiedzialności oraz odpowiednie procedury eskalacyjne. W środowisku SOA tradycyjny model raczej się nie sprawdzi. Jeżeli serwis jest dostarczany przez firmę trzecią, co się stanie w przypadku awarii? Ten serwis może być krytyczny dla działania ważnej aplikacji. W jaki sposób znaleźć wtedy miejsce wystąpienia błędu i odpowiednie rozwiązanie problemu?

Bardzo ważne jest, szczególnie w przypadku używania serwisów od wielu dostawców, bardzo jasne zdefiniowanie oczekiwań i wymagań pomiędzy współpracującymi stronami: wyczerpujące zdefiniowanie odpowiedzialności, SLA, procedur eskalacji problemów, kosztów, kar w przypadku niedostępności serwisów. Ale przecież świadomy dyrektor IT i tak to robi, prawda?

« wstecz1234 dalej »
Wystaw ocenę:
    Średnia ocena (liczba głosów: 0)
wydrukuj wydrukuj wyslij do znajomegowyślij do znajomego

Komentarze

Usługodawca

  • ocena: brak oceny
  • IP: 150.254.204.65
  • 02-09-2009, 13:07

Drogi Panie, czy nie można było użyć słowa "usługa" w zamian za spolszczenie "serwis". Ja doskonale rozumiem, że chciał Pan być jak najbliżej znaczenia "Web Service" i żargonu informatycznego, ale teraz to wygląda dość komicznie.