Chế biến một thông điệp đúng một lần

Question

Hãy xem xét kịch bản như trong hình ảnh đính kèm:

1. Cổng thông tin (sản xuất) sẽ gửi một số thông điệp tới xe buýt mà phải được xử lý bởi nhiều ứng dụng (tiêu dùng) - PAYROLLAPP, Helpdesk, vv
2. Nhiều trường hợp các ứng dụng của người tiêu dùng có thể chạy, cũng những trường hợp có thể được thêm/loại bỏ động
3. Bây giờ, điều quan trọng là đảm bảo rằng thông báo chỉ được xử lý một lần, cho mỗi ứng dụng tức là nếu PAYROLLAPP -1 xử lý thông báo, PAYROLLAPP -2 KHÔNG nên xử lý thông báo; tất nhiên, trong sơ đồ trên , HELPDESK - 1 phải xử lý nó. Tóm lại, trong trường hợp có nhiều trường hợp, chính xác một số phải xử lý thư, sau khi
4. Khi tôi tìm kiếm câu trả lời, hầu hết nội dung là về việc tạo 'người tiêu dùng chọn lọc' - người tiêu dùng chấp nhận/từ chối thư một số logic - xin lưu ý rằng không có thay đổi/bổ sung/gói có thể được thực hiện cho các ứng dụng được hiển thị trong sơ đồ; logic phải cư trú ở đâu đó trong nhà cung cấp quản lý xe buýt

Vui lòng hướng dẫn tương tự.

Thêm nhiều chi tiết sau khi Petter của câu trả lời:

1. Các mục vào bên trái của dòng trái rải rác là 'phương pháp' - JMS Chăm sóc Tóc, ESB, EAI
2. Các mục ở bên phải của đường chấm chấm phải là 'triển khai'

Bây giờ, phần lớn - QUERIES:

1. Không phân biệt các giải pháp (JMS tinh khiết, ESB, EAI), không phần dưới đường chấm chấm (hàng đợi ứng dụng cụ thể) ngang cần được thực hiện?
2. Cách sử dụng ESB (JBoss ESB, v.v.) thay vì ‘thuần túy’ JMS (Active MQ, v.v.), trợ giúp/ cản trở? ESB có cung cấp bất kỳ lợi thế nào so với JMS là 'chỉ java' (?) Hay không. Tôi địa ngục bối rối - ‘ESB hoặc JMS’, ngay cả sau khi giới thiệu các chủ đề như thế này: JMS and ESB - how they are related?. Có một câu trả lời cho biết “JMS không phù hợp với để tích hợp các dịch vụ REST, Hệ thống tệp, S/FTP, Email, Hessian, SOAP, v.v. được xử lý tốt hơn với ESB hỗ trợ các loại này một cách tự nhiên. Ví dụ: nếu bạn có một quy trình sẽ đổ một tệp CSV 500MB vào lúc nửa đêm và bạn muốn một hệ thống khác tải tệp, hãy phân tích cú pháp CSV và nhập vào cơ sở dữ liệu, ESB có thể dễ dàng thực hiện - trong khi giải pháp chỉ với JMS sẽ là xấu. Tương tự như vậy, tích hợp các dịch vụ REST, với cân bằng tải/ chuyển đổi dự phòng sang nhiều trường hợp phụ trợ có thể được thực hiện tốt hơn với ESB hỗ trợ HTTP/S nguyên bản. ”Nó chỉ thêm vào sự nhầm lẫn của tôi !!!
3. Việc sử dụng khung công tác EAI (Apache Camel, v.v.) một cách tiếp cận hoàn toàn khác với cách tiếp cận thuần túy JMS hoặc ESB? Nếu có, làm thế nào và những ưu/nhược điểm là gì?
4. Tôi được thông báo rằng chỉ riêng ESB sẽ không giúp được gì, BPM (hay cái gì khác?) Cần được sử dụng để xác định và lưu trữ logic 'định tuyến' - điều này có đúng không?

Answer 1

Tôi thấy điểm. Điều này có thể hơi phức tạp với JMS "thuần túy".

Điều cơ bản bạn muốn làm là để cổng thông tin xuất bản thư cho chủ đề, nhưng không để PAYROLLAPP đăng ký chủ đề đó (vì tất cả chúng sẽ nhận được bản sao của thư). Vì vậy, những gì bạn cần là một số logic ở giữa việc phân phối thông điệp từ đăng ký chủ đề cho một hàng đợi cho mỗi loại ứng dụng. Từ hàng đợi đó, cân bằng tải bình thường (mẫu người tiêu dùng cạnh tranh) có thể được thực hiện với JMS.

Các nhà cung cấp JMS khác nhau có triển khai đặc biệt có thể hoàn thành nhiệm vụ này ActiveMQ has its Virtual Destinations, WebSphere MQ has its server side subscriptions that can subscribe from a topic to a queue. Trong trường hợp nhà cung cấp JMS của bạn không có cách nào để xử lý việc này, bạn có thể muốn xem xét thêm một số phần mềm trung gian định tuyến vào cấu trúc liên kết của bạn. Apache Camel là một cái đẹp, nhẹ, nhưng có rất nhiều người khác có thể thiết lập một số định tuyến ở giữa mà không ảnh hưởng đến các ứng dụng thực.

Cập nhật cho câu hỏi chi tiết

1. Các Queues dưới mức phải có mặt ở đó cho chắc chắn (nếu ứng dụng của bạn sử dụng tin nhắn). Hộp "Một số phân phối logic" không cần thiết. Hộp "Một số định tuyến logic" có thể là một ESB hoặc trong trường hợp này, được triển khai trong máy chủ nhắn tin, ví dụ ActiveMQ với các đích ảo (hoặc WebSphere MQ hoặc có lẽ là RabbitMQ trong số những người khác).

2. Có rất nhiều buzwords trong miền tích hợp. Đơn giản hóa (tùy thuộc vào người bạn yêu cầu - ESB cũng có thể được xem như là một mẫu kiến ​​trúc, nhưng hãy giữ nó đơn giản), ESB là một ứng dụng máy chủ (hoặc cấu trúc liên kết của nhiều máy chủ trong thực tế). Máy chủ ESB đơn giản chứa các luồng tin nhắn và thông điệp nhỏ, lấy thông điệp (tập tin hoặc bất kỳ thứ gì) từ một ứng dụng và chuyển chúng sang nhiều ứng dụng, chuyển đổi chúng sang các định dạng khác, mã hóa, chuyển đổi từ một giao thức truyền tải như HTTP/SOAP sang File vv .

JMS là một từ khá khó hiểu và bị bỏ lỡ. Java đã ở một mức độ nào đó thống trị miền nhắn tin của doanh nghiệp trong những năm qua, vì vậy JMS đôi khi được sử dụng khá nhiều như một từ đồng nghĩa với Nhắn tin. Tuy nhiên, Nhắn tin, (hoặc tin nhắn xếp hàng, tin nhắn không đồng bộ, MOM = tin nhắn định hướng middleware, vv) là đơn giản được coi là một gia đình của giao thức vận tải tương tự có tính năng một máy chủ chuyển tiếp trung tâm. Không phải là một điều duy nhất trong Java. Nhiều thiết lập ESB thành công tôi đã làm việc với đòn bẩy thực sự trên xương sống Nhắn tin

1. Trong trường hợp của bạn, tôi sẽ không đi sâu vào sự khác biệt về mặt học thuật/triết học giữa phần mềm ESB và EAI. Họ rất có thể sẽ làm những điều tương tự cho bạn. Thay vào đó, hãy nhìn vào những sự kiện khó khăn như giá cả, hỗ trợ, dấu chân tài nguyên, giám sát, công nghệ. các tính năng, đường cong học tập, v.v. Hãy là Camel/ServiceMix, Mule, JBoss ESB, Microsoft BizTalk, IBM Broker Message, Tibco, v.v.

2. Hah! Có lẽ đó là một nhân viên bán hàng? Một ESB sẽ làm tốt. Một máy chủ Nhắn tin cũng sẽ làm trong trường hợp của bạn, chẳng hạn như ActiveMQ như đã được chỉ ra. Bộ quần áo BPM phù hợp cho việc phối hợp các quy trình kinh doanh bán tự động hóa hoặc nếu có logic kinh doanh chính trong lớp tích hợp. Nếu không, hãy tránh sự phức tạp đó.

Answer 2

1. Không phân biệt các giải pháp (JMS tinh khiết, ESB, EAI), không phần dưới đường chấm chấm ngang (hàng đợi ứng dụng cụ thể) cần phải được thực hiện?

Người tiêu dùng cần phải được thực hiện theo cách như vậy mà làm việc với bạn chọn giải pháp nhưng bạn không cần phải lo lắng về việc tạo ra các hàng đợi mỗi người tiêu dùng hoặc logic phân phối (giả định rằng người tiêu dùng có thể tiêu thụ trực tiếp từ công nghệ được lựa chọn)

1. Làm thế nào để sử dụng ESB (JBoss ESB vv), thay vì JMS 'tinh khiết' (Active MQ vv), giúp/cản trở? ESB có cung cấp bất kỳ lợi thế nào so với JMS là 'chỉ java' (?) Hay không. Tôi bối rối - 'ESB hay JMS', ngay cả sau khi đề cập đến các chủ đề như thế này: JMS và ESB - chúng liên quan như thế nào ?. Nó có một câu trả lời cho biết “JMS không thích hợp cho việc tích hợp các dịch vụ REST, các hệ thống tệp, S/FTP, Email, Hessian, SOAP… được xử lý tốt hơn với ESB hỗ trợ các kiểu này một cách tự nhiên. Ví dụ, nếu bạn có một quá trình đổ một tệp CSV 500MB vào lúc nửa đêm và bạn muốn một hệ thống khác lấy tệp, phân tích cú pháp CSV và nhập vào cơ sở dữ liệu, điều này có thể dễ dàng thực hiện bằng ESB - JMS sẽ là xấu. Tương tự như vậy, tích hợp các dịch vụ REST, với cân bằng tải/chuyển đổi dự phòng sang nhiều trường hợp phụ trợ có thể được thực hiện tốt hơn với ESB hỗ trợ HTTP/S nguyên bản. ”Nó chỉ thêm vào sự nhầm lẫn của tôi !!!

Ý kiến ​​của tôi là ESB sẽ vượt quá giải pháp này. Nó được thiết kế (trong số những thứ khác) để hỗ trợ tích hợp với các công nghệ khác nhau, nhưng các giải pháp đơn giản cũng làm điều này - ví dụ - Apache Camel cung cấp một cách giao tiếp rất dễ dàng bằng cách sử dụng rất nhiều phương tiện (bao gồm ActiveMQ).

Không phải tất cả triển khai JMS đều phục vụ kết nối từ các ngôn ngữ khác, nhưng ActiveMQ sử dụng kết nối STOMP của nó.

1. là việc sử dụng khuôn khổ EAI (Apache Camel, vv) một cách tiếp cận hoàn toàn khác biệt so với JMS tinh khiết hoặc cách tiếp cận ESB? Nếu có, làm thế nào và những ưu/nhược điểm là gì?

Apache Camel và JMS là các công nghệ bổ sung, như JMS và ESB. Camel (& Spring Integration) gọn nhẹ, đơn giản và di động. ESB là nặng hơn nhiều và thường sẽ dẫn đến khớp nối lớn hơn với máy chủ ứng dụng ESB /.

1. tôi được cho biết rằng ESB một mình sẽ không giúp đỡ, BPM (? Hay cái gì khác) cần phải được sử dụng để xác định và lưu trữ logic ‘định tuyến’ - điều này có đúng?

Nó phụ thuộc những gì logic 'định tuyến' của bạn là, có vẻ với tôi như bạn không yêu cầu định tuyến logic, bạn chỉ cần yêu cầu giao hàng được đảm bảo để 1payroll tiêu dùng và 1 quầy trợ giúp người tiêu dùng. BPM sẽ hữu ích hơn khi bạn muốn dữ liệu công khai có chọn lọc/gọi một dịch vụ dựa trên một số đặc tính của dữ liệu đó.

tôi mạnh mẽ khuyên bạn nên đọc http://activemq.apache.org/virtual-destinations.html, sử dụng các bạn sẽ:

1. Gửi tin nhắn cho người môi giới ActiveMQ, vào một VirtualTopic, ví dụ VirtualTopic.X
2. Đăng ký bảng lương và người tiêu dùng Helpdesk, như người tiêu dùng trên hàng đợi ActiveMQ tạo động trên chủ đề - ví dụ: Consumer.Payroll.VirtualTopic.X. Cả hai người tiêu dùng biên chế nên được đăng ký với cùng một chuỗi.
3. ActiveMQ sẽ tự động giữ lại điểm đánh dấu thể hiện những gì mỗi bộ người tiêu dùng không sử dụng. Điều này có nghĩa rằng 100% tin nhắn sẽ được xử lý bởi một người tiêu dùng Biên chế nhưng một tin nhắn sẽ không bao giờ được gửi đến> 1 người tiêu dùng bảng lương.
4. Thêm/xóa người tiêu dùng theo ý thích.

N.B. Tôi tin rằng các sản phẩm khác, ví dụ: Apache QPID cung cấp chức năng tương tự - tôi chỉ biết rõ nhất về ActiveMQ và đã thành công với phương pháp này