Return-Path: X-Original-To: apmail-activemq-dev-archive@www.apache.org Delivered-To: apmail-activemq-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9401F17B9D for ; Mon, 30 Mar 2015 15:53:55 +0000 (UTC) Received: (qmail 94274 invoked by uid 500); 30 Mar 2015 15:53:46 -0000 Delivered-To: apmail-activemq-dev-archive@activemq.apache.org Received: (qmail 94226 invoked by uid 500); 30 Mar 2015 15:53:46 -0000 Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@activemq.apache.org Delivered-To: mailing list dev@activemq.apache.org Received: (qmail 94215 invoked by uid 99); 30 Mar 2015 15:53:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2015 15:53:45 +0000 X-ASF-Spam-Status: No, hits=1.3 required=5.0 tests=URI_HEX,URI_TRY_3LD X-Spam-Check-By: apache.org Received-SPF: error (nike.apache.org: local policy) Received: from [162.253.133.43] (HELO mwork.nabble.com) (162.253.133.43) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Mar 2015 15:53:20 +0000 Received: from mjoe.nabble.com (unknown [162.253.133.57]) by mwork.nabble.com (Postfix) with ESMTP id CF6D41929DC8 for ; Mon, 30 Mar 2015 08:53:17 -0700 (PDT) Date: Mon, 30 Mar 2015 08:41:31 -0700 (PDT) From: artnaseef To: dev@activemq.apache.org Message-ID: <1427730091758-4694072.post@n4.nabble.com> In-Reply-To: References: Subject: Re: [PROPOSAL] Pluggable Brokers... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org This is awesome. I have been thinking of a similar idea. Separation of concerns... Core "messaging" implementation separated from the overall messaging solution, allowing multiple messaging solutions with varying needs to be maintained separately while also making it possible to replace the engine implementation easily: ---------------------- messaging-solution ---------------------- | * client API | * transaction management (including XA, if so desired) | * features (such as Virtual Topics) | * message containers (queues, topics, chat rooms, private message rooms) | * persist message for longer-term access, as-needed | | <--- *** Messaging Engine API | V --------------------- messaging-engine --------------------- * persist messages for guaranteed delivery (only; and not a required feature of the engine) * route messages * transaction support * enable enforcement of order * moving messages to endpoints NOTE: this needs more thought; the separation above may not be a good dividing line, but I hope it makes my thinking more clear. One key I see here - the ability to create a complete messaging solution that is tuned to specific use-cases (e.g. small, embedded architecture; or large, enterprise messaging backbone), while using the same engine. And, the means to replace the engine with another one as long as the API is met. James - is this in-line with your idea? -- View this message in context: http://activemq.2283324.n4.nabble.com/PROPOSAL-Pluggable-Brokers-tp4694058p4694072.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.