Czy projekt SOA może być zaprojektowany z usługą REST?

Question

Ostatnio dużo czytałem o SOA, ale większość treści jest związana z SOAP i ma wiele "biurokratycznych" rzeczy, które należą do systemów C#/Java. Szczerze mówiąc, uważam, że taka biurokracja, szczególnie SOAP, to ból w dupie. Więc, jestem ciekawy, czy SOA można zaprojektować z REST?

W tej chwili aplikacje Ruby sprawiają, że wszystkie moje kontrolery są RESTOWN. Mój interfejs sieciowy (formularze itp.) Wysyła żądania GET/POST/PUT/DELETE do rdzenia, czyli usługi sieciowej REST. Wszystkie inne systemy, które używają rdzenia, wysyłają do niego żądania REST. Czy to jest SOA?

Answer 1

Na wysokim poziomie odpowiedź brzmi Tak, jednak nie do końca.

SOA wymaga myślenia o systemie pod względem

• Services (dobrze zdefiniowane funkcjonalności biznesowych)
• składników (oddzielne kawałki kodu i/lub struktur danych)
• procesów (orkiestracji usług. Generalnie przy użyciu BPEL)

Możliwość tworzenia nowych usług na wyższym poziomie lub procesów biznesowych jest podstawową cechą dobrego SOA. Usługi sieciowe oparte na XML i SOAP oraz powiązane standardy są odpowiednie do realizacji SOA.

także SOA ma kilka przyjętymi zasadami - http://en.wikipedia.org/wiki/Service-oriented_architecture#Principles

• Znormalizowany Roboty budowlane - Usługi przylegają do układu komunikacyjnego, określone wspólnie przez jednego lub więcej dokumentów serwisowych opisie.
• Usługa Loose Coupling - Usługi utrzymują relację, która minimalizuje zależności i wymaga tylko, aby utrzymywali wzajemną świadomość.
• Abstrakcja usług - poza opisami w umowie o świadczenie usług, usługi ukrywają logikę przed światem zewnętrznym.
• Obsługa wielokrotnego użytku - logika jest podzielona na usługi mające na celu promowanie ponownego użycia.
• Autonomia usług - usługi mają kontrolę nad logiką, którą obejmują.
• Granularność usług - Uwzględnienie projektu w celu zapewnienia optymalnego zakresu i odpowiedniego poziomu szczegółowości funkcjonalności biznesowej w działaniu usługi.
• Bezpaństwowość usług - usługi minimalizują zużycie zasobów, odraczając w razie potrzeby zarządzanie informacjami o stanie.
• Wykrywalność usług - Usługi są uzupełniane o meta dane komunikacyjne, dzięki którym można je skutecznie wykryć i zinterpretować.
• Komponowanie usług - usługi są efektywnymi uczestnikami kompozycji, niezależnie od wielkości i złożoności kompozycji.

Architektura oparta na architekturze SOA ma mieć definicję usługi. Ponieważ usługi sieciowe RESTful nie mają definitywnej definicji usługi (podobnie jak w przypadku wsdl), system oparty na REST nie może spełnić większości z powyższych zasad.

Aby osiągnąć taki sam przy użyciu odpoczynek, trzeba by mieć relaksującego Web Services + orkiestracji (możliwe przy użyciu jakiś lekki ESB jak MuleESB lub camel)

Proszę również zobaczyć ten zasób - From SOA to REST

---

Dodanie tej części do wyjaśnienia poniżej komentarza -

Do komponowania procesów wymagana jest orkiestracja. To zapewnia największą korzyść z SOA.

Say masz aplikację przetwarzania zamówień z operacjami jak -

• AddItem
• addTax
• calculateTotal
• placeOrder

Początkowo został utworzony proces (używając BPEL) który używa tych operacji w sekwencji. Masz klientów, którzy korzystają z tej złożonej usługi. Po kilku miesiącach pojawia się nowy klient, który ma zwolnienie podatkowe, wtedy zamiast pisać nową usługę, możesz po prostu utworzyć nowy proces pomijając operację addTax. W ten sposób można szybciej osiągnąć funkcjonalność biznesową, ponownie korzystając z istniejącej usługi. W praktyce istnieje wiele takich usług.

Tak więc technologia BPEL lub podobne (ESB lub routing) jest niezbędna dla architektury SOA. Bez zastosowania biznesowego, SOA nie jest tak naprawdę SOA.

Krzyża pisał na moim osobistym blogu - http://blog.padmarag.com

Zobacz również nowy zasób natknąłem - REST based SOA

Answer 2

Usługa w kategoriach SOA to składnik, który rozwiązuje określony problem biznesowy. SOAP/WCF są bardziej związane z częścią interfejsu/dostawy SOA. Można również zastosować podejście REST. Kontrakt serwisowy, zasady, wersje i inne "standardowe" funkcje SOA można również wdrożyć z usługą RESTful.

Głównym REST-owym problemem jest to, że jest ukierunkowany na CRUD, dlatego nie byłby najlepszym wyborem do złożonej implementacji logicznej. Ale jeśli twoja logika biznesowa jest całkowicie CRUD (lub zbiega się z CRUD), to powinno być w porządku.

Btw, wygląda na to, że Microsoft dodał operacje do usług danych WCF, specjalnie w celu emulacji SOAP z usługą REST.

Answer 3

Najważniejszą rzeczą SOA jest miękkie czynniki np uzyskiwanie innych osób korzystać z usług i wizy versa do tego celu posiadanie łącza wsdl, z którego można zbudować łatwy w użyciu serwer proxy, jest prawie niezbędne. Usługi muszą być kompozycyjne, ale NIE potrzebujesz do tego orkiestracji, BPEL lub fantazyjnego autobusu i nie polecałbym ich, gdy zaczynasz z SOA. (w rzeczywistości po ich użyciu myślę, że można uzyskać lepsze wyniki bez nich, ale potrzebne są zdarzenia).

Uwaga: produkty takie jak WCF umożliwiają utworzenie usługi eksponującej wsdl, ale oprócz SOAP można również użyć REST/Json lub nawet lepsze binarne punkty końcowe TCP. Jest to idealne rozwiązanie, ponieważ używasz SOAP dla uproszczenia i przełączasz się na binarny (który wieje WYPUSZCZENIE z wody), kiedy potrzebujesz.

O ile SOAP idzie przez 8 lat budowania wydajnych systemów SOA z WCF, nigdy nie zauważyłem, że SOAP było nawet tam. To dlatego, że pracuję głównie w C# i mamy dobry stos SOAP .. większość innych języków nie rób.