On 10 March 2013 16:29, Fraser Adams <[email protected]> wrote: [.. snip ..] > > As a philosophical question, given all of the quirky little differences an > interesting question might be "what exactly is Qpid"? there's two AMQP > brokers, but both quite different, supporting different queue and exchange > types and even with different declaration options, I guess they evolved > separately so perhaps it's not surprising but it's *really* confusing :-)
So my take on what "What is Qpid?" is that Qpid is the Apache implementation of AMQP, and should aspire to be the de facto reference implementation of AMQP. Qpid started out speaking AMQP 0.8 which was very much a definition of a client/broker model with defined broker semantics. At the time I think it was envisioned that extensions would come through exchange types, and possibly sub-protocols (don't ask!). As the AMQP community has evolved and learned from its earlier work we have moved away from specifying in terms of a "client" and a "broker" into a notion of a network of AMQP peers. This provides for much more interesting scenarios than a strict client <-> broker <-> client model. Because of the history of Qpid, where people wanted to use AMQP but a feature was not standardised in the protocol, then the temptation has been to add bespoke extensions into our implementations to meet those requirements. This has led to the two brokers growing functionality often in similar but incompatible ways as developers have dine their best to meet users needs from messaging products. In hindsight we could definitely have managed this feature growth in a better way. What I would like to see going forward is that we align our implementations with AMQP standards... where we have a feature that isn't a standard then we look to see how we can get that feature "standardised". Where a feature is being standardised then we as the Apache Qpid community should be looking to be amongst the first, if not the first, to implement. Many members of the Apache Qpid community are prominent players in the OASIS AMQP standardisation process... Steve Huston chairs the Bindings and Mappings Techincal Committee, I am one of the two co-chairs of the core AMQP Technical Committee, Rafael Schloming and I were both editors of the AMQP 1.0 specification. What does this mean in terms of branding, cohesion and interoperability? I think if people want to use AMQP, Qpid should be their first port of call. We should be aiming to be *the* place people go for libraries and components which interoperably speak AMQP 1.0. Interoperability doesn't just mean within the Qpid suite, but with all other AMQP compliant implementations. That means a lot more focus on "client" libraries than we have previously had. In terms of the existing brokers... As above would be focussing on driving interoperability and cohesion by driving standards. While it is useful for the Java and C++ brokers to do the same things in the same way... it is *much* more useful if I can also use the same tooling to make ActiveMQ, Microsoft's ServiceBus or SwiftMQ do the same thing. I know Justin has suggested retrospectively naming the existing brokers so that we can better distinguish between the Qpid project and the existing components... as the project as a whole aims to be much more than a couple of message brokers and client libraries aimed at working with them. I'm not sure how I feel about that, but we do need to do a much better job at articulating what the project vision is, and who is the target user for the various components that make up the whole. The above are my personal views - I'm sure others may differ, and I'd be interested to hear their thoughts. -- Rob > > I've mentioned this casually to Gordon Sim, but I think that I'm more > adamant about this than ever now. I *really* think that some effort needs to > be put into "branding" Qpid. Part of that is about providing maximum > cohesion and interoperability between the brokers and the client libraries. > > Particularly now that Proton appears to be being used in say ActiveMQ for > AMQP 1.0 support I think it becomes all the more important to have the "big > set of features" like you have on shrink wrapped software so users know what > Qpid is and so when someone is tasked with selecting between a big list of > Messaging platforms it really jumps out why Qpid is the right choice!! > > > Cheers, > Frase > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
