• Save
WebSphere Service Registry Repository - nie jest wyłącznie rejestrem & repozytorium usług. Czyli jak zbudować elastyczne i bezpieczne ESB.

Like this? Share it with your network

Share

WebSphere Service Registry Repository - nie jest wyłącznie rejestrem & repozytorium usług. Czyli jak zbudować elastyczne i bezpieczne ESB.

  • 1,153 views
Uploaded on

Andrzej Kowalczyk

Andrzej Kowalczyk

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
1,153
On Slideshare
1,153
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Important Points On This Slide: Scenario shows that SOA governance is just as much if not more an organizational issue (funding model, ownership, incentives to do the right thing, etc.) than a technical one. However, technical issues like enterprise wide design, proactive monitoring to understand scaling and timing still need to be addressed. Speaker Notes: This slide uses animation and will have <click> cues in the speaker notes to help the speaker along. This scenario discusses what happens when you don’t have SOA governance and describes the need for SOA governance in an SOA. The slide builds, so view in presentation mode. This scenario was a result of a lack of: An ownership model that discusses who owns and is responsible for funding throughout the lifecycle of a service. Ideally the funding model will incent providers to produce high quality services and allow them to recover their costs for developing and maintaining services or even generate additional revenue for taking on these challenges. Guarantees (could be contractual) for the consumers that a service would operate as planned with consistent quality to incent them to accept the provider as a formidable dependency. Without such guarantees, consumers are potentially put in harm’s way by depending on distributed functionality that they have no control over. It also shows what happens when you do not take a holistic approach to designing services. You need to have an idea of the amount of load placed on a service and design to that load. Since the accounting dept in our scenario was assuming that they were the only ones to use it, there initial design was probably “good enough”. However, as soon as other consumers started to use it, this should have been a key
  • Speaker Notes: Versioning compatibility is more than just the interface. There are 4 primary parts of a service: behavior, interface, interaction, and operation. Roughly this is the functional semantics of what the service will provide, its interface, its binding, and its operational characteristics and policies. This is important as the interface could stay the same and the binding change and the service is incompatible. With behavior it becomes more subjective since it is humanly defined and observed. Operational is optional (since interaction can happen, even if response time is slow, for instance). Determining impact, or if there is impact, is critical. Take binding, if a provider wants to change from SOAP/HTTP to SOAP/JMS they could (a) make the consumers do it (it is incompatible) or (b) do it themselves. To do it themselves may mean a mediation is used, which implies they are supporting both (HTTP and JMS), via the same service (with 2 bindings, at least for some period of time). In order to know if they need to do this (invest that effort/cost/risk) they have to understand impact, and impact cannot be understood without determining how versions will be properly supported. Service versioning is about managing change; reducing its affects on consumers while adding flexibility for providers. For SOA this implies that the provider will do things like reduce the impact of change to the consumer, and if necessary properly notify the consumer. Note: retirement becomes easy……if you know there are no consumers. Migrating consumers to a ‘later’ version becomes key in making retirement easy. Understanding how versions relate (what is a ‘later’ compatible version for instance) … This slide uses animation and will have <click> cues in the speaker notes to help the speaker along. This scenario discusses what happens when you do not have a service versioning strategy describes the need for SOA governance around service versioning in an SOA. The slide builds, so view in presentation mode. This scenario was a result of a lack of: A service versioning strategy to make every attempt to maintain backwards compatibility with previous service interface versions. A service versioning strategy to properly track which versions of a service interface are being used by which consumers. A service versioning strategy to create a new service if every attempt to maintain backwards compatibility with a previous service version cannot be maintained, A service versioning strategy to notify consumers of the availability of a new version. -------------------------------- How is it possible to even keep track? How to determine the potential impact (without clearly knowing consumers)?
  • EndPoint Lookup This node is a generic node in that it retrieves the service endpoint information related to a WSRR defined service (e.g. WSDL). It does not perform additional filtering or selection; other than that specified by the property matching. If a single service (Web Service only) is requested (Match Policy is One), it will set the endpoints in the context so that this service information is correctly placed in the domain context in order that existing WMB builtin nodes will correctly invoke the service. Note: This node is independent from any other domain context. Support is currently limited to query for endpoints for Web Services. RegistryLookup Node This node is a generic node that retrieves the meta-data related with a WSRR entity. It does not perform additional filtering or selection; other than that specified by the property matching. It also does not resolve endpoints, do content based routing, or set domain context for execution of the target service. It is up to the message flow developer to perform all those functions. This could still be WSDL
  • The EndpointLookup node can be placed directly prior to SOAP or HTTP Request nodes so that the endpoint address invoked by the request node is dynamically retrieved from WSRR to enable governance etc
  • Only one service is needed to bring down your SOA. There is a famous Gartner Quote on this. This is a typical example of why governance is important in day one of a SOA. If governance was in place the service would have been Owned and Funded properly Architected properly Provisioned properly Operational controlled properly
  • Only one service is needed to bring down your SOA. There is a famous Gartner Quote on this. This is a typical example of why governance is important in day one of a SOA. If governance was in place the service would have been Owned and Funded properly Architected properly Provisioned properly Operational controlled properly
  • Web Services Policy 1.5 - Framework (WS-Policy). This defines an abstract model and an XML-based expression grammar for declaring policies. Web Services Policy 1.2 - Attachment (WS-PolicyAttachment). This defines mechanisms for associating policies with the subjects to which they apply.

Transcript

  • 1. WebSphere Service Registry Repository – nie jestwyłącznie rejestrem & repozytorium usług.Czyli jak zbudować elastyczne i bezpieczne ESB.Andrzej Kowalczyk © 2012 IBM Corporation
  • 2. WSRRWSRR pełni rolę: • Service Registry dla Business’u • Service Registry dla SOA Governance • Service Registry dla Operacyjnego • Service Registry dla Dewelopmentu
  • 3. Przykłady zastosowań
  • 4. Relacje pomiędzy usługami - SOA Governance Konsument Konsument Konsument Konsument Konsument Konsument Konsument x x x Konsument x x Calculate x x Audit Currency payment Service 1.0 Service 1.0 Service 1.0 Czesław Ala Mietek Audit Service 1.1 Usługa currency Czesław parametry Aplikacje nieświadome Mietek tworzyCzesław tworzy i service stworzona Inni użytkownicy audit service zmian generują błędy calculatewdraża audit Zaczynają używać I powiadamia Administratorzy tracą przez Alę używa payment serviceservice Tych usług Użytkowników, czas (generują koszty) audit service 1.0 wykorzystując o których wie na znalezienie awarii currency service
  • 5. Kontrola nad wersjami w SOA Governance Konsument Y Konsument X Konsument 1 Konsument N Jak utrzymywać obecnych konsumentów, bez konieczności zmian? x Jak wykryć, że nowy ‘N’ty konsument może być Currency wspierany? Service V2.0 Jak zmigrować bieżącą W jaki sposób x wersję do nowej? konsumenci dowiadują się Currency Service 1.0 o nowej usłudze? Czy Jak i kiedy właściwie zdają sobie sprawę z powiadomić istniejących Currency innych wersji usługi? konsumentów? Service VN.0 Która wersja jest właściwa dla nowego konsumenta? Czy istnieje jakiś konsument tej wersji?Konsument 1 żąda Konsument Y żąda V2.0 stworzona Nowy konsument N Wkrótce wiele wersji zamian w usłudze I wdrożona dla V1.0 musi być żąda zmian do wersji Jest utrzymywanych.nowej usługi.Tworzona i wdrożona Currency Konsumenta Y. usuwana. V2.0. Zmiana jest IT generuje kosztyCurrency Service Service. Zamian jest Konsument X Konsument 1 niekompatybilna z V2. ŚLEDZĄC który konsumentV1.0. Konsument X niekompatybilna z ponosi koszty jest zmuszony Wersja N.0 jest używa której.zostaje V1.0. zmian do V2.0. używać Tworzona i Wersji, ciężkieużytkownikiem V1.0. V1.0. uruchomiona wprowadzenie zmian.
  • 6. Jak są powiązani konsumenci?• Szybki podgląd – Co używa i w jakiej wersji usługi? – Które z wersji usługi zależą od innych?
  • 7. Dynamiczne środowisko ESB
  • 8. Dynamiczny wybór adresów „hard code” ProgramistaTester ESB Architekt
  • 9. Dynamiczny wybór adresów ProgramistaTester ESB WSRR Architekt
  • 10. Dynamiczny wybór adresówUsuwa „hard-coding” portów i adresów w ESB Zmiana konfiguracji ESB podczas migracji Zmiana wyłącznie konfiguracji WSRRŚrodowisko deweloperskie Środowisko Testowe różne różne adresy adresyklienty klienty Miejsca Miejsca docelowe docelowe WSRR
  • 11. Dynamiczny wybór adresówWybór endpoint’u z WSDL’a lub pobranie go dynamicznie w runtime’ie Wybór endpoint’u z WSDL WSDL definiuje WSRR Endpoint wybrany specyfikację interface’u zgodnie z WSDL Wybór dynamiczny w runtime WSDL definiuje WSRR Endpoint wybrany specyfikację interface’u dynamicznie
  • 12. Message Broker & WSRR• Dwa węzły wykonujące zapytania do WSRR• Wyniki zapytania przesyłane do końcówki Out Failure Failure In Out In Out NoMatch NoMatch• Podobne właściwości i działanie – RegistryLookup pobiera dokumenty – EndpointLookup pobiera informacje o usługach
  • 13. Użycie węzła EndpointLookup w przepływie WSRR query endpoint service information definition (WSDL address etc)
  • 14. Wybór usługi• Kiedy docelowym protokołem jest SOAP/HTTP Web Service – Użyj węzła EndpointLookup do wybrania odpowiedniego adresu • Ustaw “Match Policy” = “One” – Użyj dowolnego węzła wejściowego (MQ, HTTP, JMS itd) – Połącz węzeł SOAP/HTTPRequest bezpośrednio do wyjścia z EndpointLookup
  • 15. Wybór usługi• Kiedy docelowym protokołem NIE jest SOAP/HTTP Web Service – Użyj węzła RegistryLookup do pobrania właściwych informacji (to też może zawierać informacje o „endpoint”!) • Ustaw “Match Policy” = “One” – Użyj dowolnego węzła do transformacji aby ustawić adres dla „endpoint’u” i właściwy nagłówek dla protokołu
  • 16. Dynamiczne transformacje XSL• Transformacja komunikatu z użyciem arkusza pobranego z WSRR – Użyj węzła RegistryLookup do pobrania arkusza XSL • Ustaw “Match Policy” = “One” – Użyj węzła transformacji node w celu skopiowania copy i zwrócenia właściwego arkusza do komunikatu wejściowego – Użyj węzła XSLTransform do transformacji komunikatu używając załączonego arkusza
  • 17. Wybór pomiędzy wieloma usługami• Np. wybór pomiędzy usługą premium i standard – Użyj węzła EndpointLookup do pobrania zestawu endpoints’ów • Ustaw “Match Policy” = “All” – Użyj węzła transformującego do wybrania właściwej usługi i skopiuj dane o „endpoint” we właściwe miejsce w nagłówku dla węzła SOAP• Alternatywnie, użyj rozgałęzienia w przepływie i dwóch węzłów EndpointLookup
  • 18. Alternatywny dostawca usługi• Końcówka „Failure” jest używana do oznaczenia problemów podczas dostępu do usług za pomocą węzła SOAP Request – W tym przypadku oznacz, który endpoint nie działa w drzewie „Environment”, powróć do przepływu, sprawdź oznaczenie (flagę) jeśli jest ustawiona wybierz nową usługę – Pamiętaj przekopiować wszystkie sytuacje “all services failed”• Użyj węzła RegistryLookup dla innych protokołów niż SOAP/HTTP (jak poprzednio)
  • 19. Wersjonowanie usług WSRR i nowe wersje endpoint dla nowych usług 1. Usługa w wersji 1.0 zarejestrowana w WSRR oraz wystawiona na DataPower 2. Klient wywołujący operację w wersji 1.0 przekierowany do endpoint’u 1.0 3. Usługa w wersji 1.1 zarejestrowana w WSRR oraz wystawiona na DataPower 4. Wywołania klienta dla operacji w wersji 1.0 przekierowywane do endpoint’u 1.0 5. Wywołania klienta dla nowej operacji w wersji 1.1 trafiają do endpoint’u 1.1 6. Usługa w wersji 1.0 wyrejestrowana z WSRR 7. Wszystkie wywołania klientów trafiają do endpoint’u 1.1CustomerInfoService-1.0getAddress CustomerInfoService-1.1 WSRRupdateAddress getAddress updateAddress getHistory ess A ddr updateHistory get wersja 1.0 getAddress ESB getA ddr getHistory getH ess isto ry klient wersja 1.1
  • 20. Polityki
  • 21. IBM Policy & Service Level ManagementUżycie polityk do kontroli SOA WSRR Visibility and Control • Redukcja kosztów i zwiększenie operacyjnej efetywności w przedsiębiorstwie • Zwiększenie elastyczności środowiska poprzez szybkie stosowanie polityk i SLA w odpowiedzi na zmianę biznesu • Centralnie zarządzanie i nadzór nad usługami i stowarzyszonymi politykami wystawionymi przez „ServiceGateway” • Automatyczne wdrażanie operacyjnych DataPower ITCAM for polityk i SLA dla usług wystawionych SOA Platform przez „ServiceGateway” • Powiadamianie i proaktywana reakcja na zmianę sytuacji i wyzwania w środowisku SOA
  • 22. SLA
  • 23. Dlaczego Nadzór jest istotny?Sprzedaż Księgowość Dział prawny App. 1 App. 2Obsługa Zakupyzamówień Usługa konwersji walut1. Usługa 2. Inne 3. Piony 4. Usługa 5. Chwilowo 6. Kosztykonwersji walut piony zwiększają naprawiona naprawione ale wzrosną /dedykowana dla ilość wywołań/ problem dostawcakonkretnego zaczynają cierpi jakość na koszt pojawia się wyłączy usługępionu używać usługę dostawcy ponownie
  • 24. Governance Enablement ProfilePołączony nadzór – Service Provider / Service Consumer Service Provider Service Consumer Organization Business Service Business Application Organization Service Version Application Version WSDL Document Service Level Agreement Service Level Definition
  • 25. Jak sterować SLA? 2 Komunikaty 3 Komunikaty na na 10 Komunikatów na sekundę sekundę sekundę Sprzedaż Księgowość Dział Prawny App. 1 App. 2 Obsługa Zakupy zamówień Usługa konwersji walut Odrzucenie niepowołanych1. Usługa 2. Inne 3. Nowa polityka 4. Działy Prawny 5. Dział prawny 6. Dział prawnykonwersji walut piony & oraz Sprzedaż przekracza limit.dedykowana dla zaczynają pozwala odrzucać negocjują SLA negocjuje Bez wpływu nakonkretnego używać wzrost SLApionu usługę niechcianych inne piony konsumentów „rogue”
  • 26. Jak to działa w rzeczywistości?
  • 27. Rozszerzona Parametryzacja Szerokie wykorzystanie WSRR to kontroli i sterowania usługami SLA CustomerInfoService Zezwala wywoływać usługi klientowi B getAddress WSRR updateAddress getHistory updateHistory ?Klient A Adres docelowyKlient B
  • 28. Różne typy polityk Agenty Monitoringu (zbiera SNMP & WS-Management metryki)Konsument 1 Service Level Definition: Pol Kon ityka d Usługa wspierana do 500 sum la request’ów / na godz. enta 1 Servic Polityka dla e Konsumenta2 PolicyKonsument 2 Service dla ka 3 olity enta P um s Service Level Agreement: Kon Konsument może wywołać 100 request’ów / na godz.Konsument 3 Wymuszany na DataPower (Pobiera WS-Policy attachments oraz policy documents)
  • 29. WSRR steruje politykami SLA WSRR UI Model Policy & C a p a b i l it y C a p a b i li t y SLAs V e r s io n V e r s io n c o n s u m e rId = 1 2 3 SLA SLA c o n te x tId = G o ld SLD AAAvvvaaai il ilalaabbbl lelee Policy C o n s u m e r I D l o c a t io n EEEnnndddpppoooi innnt tstss i C o n te x t ID lo c a tio n O ApA vev araai il ltaa obbnl lee i s EE nn dd pp oo i nn t tssi Po WSRR Consume WSDLs Monitor Monitoring Agent & Security Policy Txs DataPower App1 Enforce Policy & SLAs Service DP Developer App2 SLA Autor Polityk DP Policy Przed
  • 30. Mediation Policy Szybkie i proste tworzenie polityk „Mediation policy” Warunków oraz Akcji
  • 31. Dodawanie PolitykDodawania politykdo kontekstu – np.:podczas tworzeniaSLA
  • 32. Dodawanie PoliykDodawanie politykDo konkretnychelementów Przypisywanie do grup i zdefiniowanych zapytań
  • 33. Wsparcie dla REST SLA dostępne dla usług REST, interfejsów, endpoints poprzezprzypisanie im SLD tak samo jakdla Web Services, SCA czy MQ
  • 34. WS-Security
  • 35. WSRR Tworzenie polityk• WSRR dostarcza kompletne narzędzia dla tworzenia dokumentów WS-Policy. Obejmuje to: – Web Services Policy 1.5 - Framework (WS-Policy). – Web Services Policy 1.2 - Attachment (WS-PolicyAttachment).• WSRR także dostarcza przeglądarkowy edytor dla dokumentów. WS-SecurityPolicy Assertion 1: basicAuth required Assertion 2: sig required WS-Policy Attachment WSDL
  • 36. Stosowanie Polityk Bezpieczeństwa Polityki w działaniu Policy CustomerInfoService Polityka Szyfrowania Wymagane Zaszyfrowanie getAddress WSRR updateAddress Attachment getHistory Polityka SzyfrowaniaCustomerInfoService:updateHistory updateHistory updateHistory updateHistory [zaszyfrowany] [czyste] Docelowy adres klient Uwaga: dobra praktyka wymaga bezpieczeństwa tzw „ostatniej mili”.
  • 37. Pytania?