2009-08-12 11 views
8

Jakie są obowiązki silnika orkiestracji a systemu opartego na wiadomościach.Architektura orkiestracji a architektura napędzana wiadomościami

Jeśli muszę zbudować system, który musi łączyć ze sobą różne niezależne komponenty (komponenty międzyplatformowe/platformy, które nie muszą odsłaniać punktu końcowego usługi sieciowej), który zestaw narzędzi zostanie wybrany?

Czy jest lepsza opcja?

Odpowiedz

0

Podczas gdy to pytanie jest oznaczone jako Java, obawiam się powiedzieć, że najlepszym narzędziem, jakie widziałem, jeśli naprawdę musisz jechać, jest Microsoft's BizTalk Server.

Gdy miałem zrobić ocenę tego typu produktu (i to było kilka lat temu) było góruje nad konkurencją z głównymi funkcjami są:

  • Visual Studio jako rozwój środowisko
  • ładne wizualne narzędzia do opisania przepływów pracy i transformacje
  • rozszerzalna architektura złącze służy do podłączenia do uczestników
  • mocny silnik workflow z raportowania wielki realtime

W końcu wybieramy keep-it-simple i przeszedł trasę wiadomości, chociaż wymaga to kontroli nad wszystkimi uczestnikami, co może nie być prawdą.

2

Skorzystaj z openESB z edytorem netbeans lub z dowolnego innego silnika BPEL typu open source, który zapewnia standardowy sposób lub orkiestrację procesu. jeśli uważasz, że wydajność jest bardzo ważna niż standaryzacja, możesz wypróbować niektóre autorskie narzędzia ESB lub BPM, takie jak JBoss jBPM lub mule ESB itp.

Uwaga: BPEL może być używany tylko do korzystania z usług internetowych, jeśli twoje komponenty nie są usługami sieciowymi, być może będziesz musiał użyć ESB, takiego jak Mule, który może obsługiwać ponad 200 protokołów z rozszerzeniami.

1

Przy podejmowaniu decyzji, czy należy korzystać z przepływu pracy w ramach orkiestracji, czy wiadomości, najważniejsze pytanie, które napotykasz, czy uważasz, że konieczna będzie regularna zmiana przepływu pracy orkiestracji. Jeśli uważasz, że Proces Biznesowy musi być elastyczny, ponieważ może ulec zmianie, zastosuj format Wiadomości Kanonicznej i użyj Orkiestracji, co zminimalizuje wpływ zmieniających się relacji między usługami. Jeśli uważasz, że przepływ pracy jest stabilny, możesz przyjąć przepływ pracy sterowany komunikatami. Osobiście uważam, że Orchestration jest ogólnie lepszym podejściem, jednak wymaga większej infrastruktury oprogramowania, która dzięki takim narzędziom jak Apache Camel inwestycja to czas z nagrodą za zwiększoną długoterminową elastyczność.

0

Proponuję, abyś najpierw ujawnił swoje pojedyncze niezależne komponenty jako usługę przez Internet (nie rozumiałem, czy masz już do tego usługi sieciowe). Po tym .. najlepszy wybór zależy od obciążenia/złożoności systemu.

Zasadniczo można wybrać między usługą Orkiestracja a choreografia. Orkiestracja usług, wykonana za pomocą BPM/BPEL/ESB, jest wyborem architektonicznym, w którym pojedynczy komponent (orkiestrator/kompozytor usług) wie, jakie czynności należy wykonać i jest odpowiedzialny za wywoływanie usług w odpowiedniej kolejności (skonfigurowanych na samym orkiestratorze) . Obsługuje również zarządzanie transakcjami (w razie potrzeby).

Przeciwieństwem jest choreografia, w której każda pojedyncza usługa tworząca cały system wie, jak postępować, gdy otrzyma określoną wiadomość. W rzeczywistości jest to kwestia porozumienia między różnymi komponentami. Service Choreography to zdecentralizowane podejście do problemu składu usług.

Jeśli masz dużo usług, skomplikowane reguły i tak dalej ... prawdopodobnie łatwiej będzie korzystać z orkiestratora serwisowego, takiego jak jBPM lub coś w tym stylu.