Czy orkiestracja jest odpowiedzialnością ESB?

Question

Jest korporacyjną magistralą usług (narzędzie działające jako mediator, broker komunikatów, element wspomagający działanie, wzmacniacz transformacji schematu, przezroczysty dostawca lokalizacji, agregator usług, moduł równoważenia obciążenia, monitor i wszystkie inne elementy) odpowiada za orkiestrować usługi?

Co powiesz o zautomatyzowaniu procesu biznesowego z ponad tysiącem kroków i dziesiątkami wywołań usług wewnątrz magistrali usług dla przedsiębiorstw?

Czy zrobiłbyś to, czy też użyłbyś specjalisty od orkiestracji, na przykład silnika BPEL?

Proszę, proszę o opinię.

Answer 1

Tak i nie. Istnieje cienka, a czasami nie do odróżnienia linia między orkiestracją a powiększaniem agregacji/usług.

Ogólnie rzecz biorąc, jeśli masz długotrwały lub złożony proces biznesowy (kluczowym słowem jest proces, chociaż zamierzam go unikać), to najlepiej pasuje do BPEL.

Proste zadania, takie jak agregowanie wyników trzech zgłoszeń serwisowych, mogą i często powinny być wykonywane w warstwie ESB.

Nie warto tracić zbyt wiele snu nad, chociaż

Disclaimer: Jestem konsultantem IBM ESB, chociaż ja nie piszę tego w charakterze urzędowym.

Answer 2

Moja krótka szybka odpowiedź brzmi: NIE, to nie jest jej odpowiedzialność.

Wolałbym, żeby to było w pakiecie BPEL lub BPM.

Mhh Nie wiem co jeszcze dodać :) ... Powodzenia?

Answer 3

Teraz moja własna wizja.

Jeśli chodzi o całą pracę, jaką ma do wykonania ESB, umieszczenie organizacji usług w głównym elemencie infrastruktury SOA nie jest dobrym pomysłem.

Kruszywo, ok! Ale utrzymanie kanału komunikacyjnego zajętego logiką biznesową z pewnością spowoduje straszliwy wpływ na możliwość dostarczania innych funkcji.

Wszakże większość ESBs taką jak BEA AquaLogic usługi mają ograniczoną obsługę orkiestracji tym brak stanowych możliwości i działań, takich jak wait (timer) lub podnieść (czekać na jakiś wkład do ruchu w procesie), możliwości dzielenia/łączenia (już dodane w ALSB 3.0) i tak dalej.

Nie ma mowy. Wystarczy użyć narzędzi takich jak silnik BPEL lub narzędzie takie jak Weblogic Integration.

Dzięki.

Answer 4

Ilekroć masz dwie lub więcej usług, które współdziałają z usługującym orkiestratorem usług, tj. Dla usług związanych ze składem i kontrolą procesu. Jeśli masz esb ujawnić tę usługę składowania na esb. Teraz, jeśli musisz skomponować nową usługę, która obejmuje tę usługę składu, użyj orchestratora i ponownie wystaw na esb. Użyj esb jako mechanizmu dostarczania usług i brokera usług sieciowych oraz serwera proxy.Podczas komponowania orkiestratora serwisowego użyjesz esb, aby dotrzeć do usług wchodzących w interakcje. Jeśli te usługi interakcyjne korzystają z niekompatybilnych schematów XML, esb może je przekształcić/odwzorować na wspólny schemat w środowisku wykonawczym i zlecić obsługę żądań na podstawie zawartości, np. przestrzeń nazw.

Answer 5

Taka orkiestracja jest w większości przypadków odpowiedzialnością ESB. Lub, alternatywnie, jeśli narysujesz linię między infra ESB i orkiestracji, to robisz to na poziomie fizycznym ze względu na wydajność, a nie dla logicznego przypisania odpowiedzialności.

Masz dwie możliwości - kiedy, na przykład, system HR otrzymuje nowego pracownika - gdzie umieszczasz logikę biznesową, która mówi: "dział zgodności musi najpierw zatwierdzić i sprawdzić, a jeśli to w porządku, Dział HR będzie musiał sfinalizować wynajem, następnie dział księgowości będzie potrzebował nowego wpisu, a następnie system płac będzie wymagał aktualizacji, a jeśli to się nie powiedzie, będziemy musieli wysłać e-mail do HR "? Jeśli wszystkie procesy biznesowe są uważane za "posiadane" przez dział inicjujący/aplikację, wówczas cały system, który jest przedsiębiorstwem, staje się złożony, z odmiennymi systemami orkiestracji.

Drugim wyborem jest scentralizowanie orkiestracji, co czyni ją logicznym partnerem platformy komunikacyjnej. Jeśli zdecydujesz się zobaczyć je jako osobne artefakty, to zależy od Ciebie, ale jest równie ważne, aby opisać je zarówno jako ESB.

Answer 6

Nie, odpowiedzialność ESB nie polega na organizowaniu usług (per se). ESB zapewnia warstwę abstrakcji na "poziomie infrastruktury oprogramowania".

Oznacza to, że ESB jest "pojedynczym logicznym abstrakcyjnym portem połączenia" z dowolną usługą opublikowaną w magistrali.

ESB jest abstrakcyjna, oznacza, że ​​konsumenci usług w autobusie nie "potrzebują" szczegółowych informacji o wdrożeniu usługi i możliwe jest odsłonięcie "usług wewnętrznych" za pomocą jednego modelu dokumentu. ESB zapewnia usługi niskiego poziomu (takie jak translacja protokołów i transformacja komunikatów), dzięki czemu wewnętrzne usługi mogą komunikować się w uproszczony sposób.

Oznacza to pewną orkiestrację: ESB zapewnia orkiestrację wyżej wymienionych usług niskiego poziomu (np. Gdy usługa X jest wywoływana przez IIOP, przetłumacz to na SOAP z załącznikami, a następnie przekształć żądanie z dowolnych serializowanych danych na ładunek XML) .

Instrumentacja, której zwykle unikasz w ESB: Aby przetworzyć tę sprzedaż (ubezpieczenie), najpierw musimy zweryfikować informacje dostarczone przez kupującego, wtedy musimy zabezpieczyć ryzyko ubezpieczenia, a na końcu obliczyć składkę, którą trzeba zapłacić za ubezpieczenie, po czym musimy ... itd.

Kroki opisane powyżej są oczywiście procesem biznesowym (który może nawet zostać przerwany ... np. jeśli automatyczne ubezpieczenie nie jest możliwe, wtedy człowiek underwriter musi dalej oceniać ryzyko).

Usługi biznesowe (np. Walidacja, ubezpieczenie, obliczanie składki), które składają się na proces biznesowy (np. Sprzedaż ubezpieczeń), co jest zwykle określane jako orkiestracja, najlepiej nadaje się do zastosowania w silniku procesów biznesowych i definiowane przy użyciu sformalizowany język modelowania procesów biznesowych (taki jak BPEL).

Zgadzam się także z wieloma etapami procesu: W powyższym przykładzie walidacja jest usługą (oczywiście złożoną). Same zasady walidacji są wewnętrzne dla tej usługi. W przypadku złożonych reguł biznesowych (tzn. Nie procesów biznesowych) może być wymagane użycie mechanizmu reguł biznesowych.

Answer 7

Magistrala usług korporacyjnych nigdy nie powinna być odpowiedzialna za organizację usług.

Orkiestracja oznacza minimum "sprytów", w szczególności zdolność do kompensowania nieudanych transakcji. Narzędzia magistrali usług często mówią, że oferują "try-catch" lub coś podobnego, ale zdolność do uruchamiania scoped componsation jest oznaką właściwego narzędzia orkiestracji. Dodatkowo możliwość oczekiwania, znajomości własnego stanu lub trzymania rzeczy w niepewności jest kolejnym wskaźnikiem, że masz do czynienia z orkiestratorem, a nie autobusem.

Mówiąc do ponad 1000 kroków i dziesiątki usług, należy rozważyć, czy jest to w toku. Jeśli wszystkie instrukcje if-then w 1000 krokach mówią tylko o routingu bez zmian w ładunkach, to nadal jesteś w "routingu", a więc nadal w ESB. Ale jeśli jest jeszcze jeden zagnieżdżony if-then i zacznę szukać różnych narzędzi. Poza tym, jeśli te, które wyglądają jak rutowanie, mogą bardzo szybko wpłynąć na logikę biznesową. Gdy logika biznesowa zaczyna się pojawiać, lepszy jest lepszy język, taki jak BPEL lub BPMN.

Przykład dyrygenta orkiestry jest często podawany w celu opisania działania orkiestracji, głównej osoby kierującej muzykami według partytury. Często pozostaje to, że dyrygent nie tylko reżyseruje, ale też słucha, a jeśli coś pójdzie nie tak, może zrekompensować to w wiarygodny, powtarzalny sposób.

Na przykład wyobraźmy sobie, że nasz pierwszy dyrygent przynosi gracza tuby, ale powiedział, że tuba zdecydował się zrobić coś innego. Prosty "orkiestrator" w stylu pinballa wprowadzi sekcję tuby, wiedząc doskonale, że jej tam nie ma, a następnie czeka na publiczność, aby później narzekać. Naprawdę doświadczony przewodnik zobaczyłby, że tuba zniknęła, i natychmiast przywołają głębsze barytonowe rogi, aby to zrekompensować.