Microsoft Embraces AMQP Open Middleware Standard 122
AlexGr writes to tell us that Microsoft apparently has plans to embrace a little known messaging standard called AMQP (Advanced Message Queuing Protocol). Red Hat, a founding member of the AMQP working group, was very excited about the news and wrote to welcome Microsoft to the party. "Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail. The proprietary message oriented middleware (MOM) products on the market today like IBM's MQ or Tibco's Rendezvous fulfill the same function as AMQP. But they operate exclusively in single-vendor fashion and utterly fail to interoperate with each other. They are also — perhaps not by coincidence — burdensomely expensive. As a result their use is mostly limited to wealthy organizations such as Wall Street banks (at least the ones who are still in business) that need to exchange huge volumes of business messages very reliably and very quickly. But AMQP's supporters feel the market for such reliable messaging could be much larger if a less expensive and truly open solution became available."
Embrace, something, something (Score:5, Insightful)
Re:Embrace, something, something (Score:5, Funny)
Re: (Score:2, Funny)
No, I think their plan might be more like...
1) Embrace
2) ?
3) Profit!
If that doesn't work, Plan 'B' will probably involve throwing some chairs around while cursing.
Re: (Score:2)
As the saying goes ... (Score:2)
I say that with a full understanding that this is effective business; their profitability and control of the industry speaks well enough for that. No, really -- if I wanted to find out how to be effective in the business world, I would definitely study tactics used by Microsoft and organizations like them. They have quite a genius for it and I acknowledge this freely. I just happen to be m
Re: (Score:2)
Yes, let's trumpet the most base qualities in humans and declare them to be the standard for business. What right should we have to expect ethical behavior since there is no one to enforce it or that the entity isn't human, merely run by humans?
Tell you what, let's make a list of the worst excesses of human behavior and pass it around to companies to use as a cheat-sheet. Business School Product should always aim high.
Gerry
Re: (Score:1)
Same old lil' penguins...
1. Damn Microsoft and their proprietary protocols!
2. Damn Microsoft for using standards based protocols!
It's not "don't fear the penguins"... It's "don't be afraid little penguins."
Re: (Score:3, Insightful)
So tell me, Mr Anonymous Coward and all who modded you up - what should Microsoft do? Just lie down and die because you dislike them?
Re: (Score:2)
Some people do learn from history you know...
The microsoft way has always involved being as proprietary as possible to force users onto their products, and if that means a temporary use of open protocols to temp users over before screwing them over and locking them in, then that's what they do.
History has taught us to be extremely wary of microsoft's actions, and that they will not hesitate to screw people over given the chance.
Re: (Score:2)
If they "can't win" that is their problem. Isn't that simple enough?
They have caused so many problems with "embrace and extend" practices that there is a reason why t
Re: (Score:2)
Re: (Score:2)
But if they decide to adopt a given standard, the first thing you hear on Slashdot is 'Embrace, extend, extinguish!!'. They can't win.
Sure they can. It's simple. All they have to do is stop engaging in dishonest, underhanded, unscrupulous, blatantly anti-competitive behavior for a few years, and blammo, people will gradually stop assuming the worst every time they do something[*]. As long as people who assume the worst of them are right more often than they're wrong, they've got nobody but themselves to blame for the fact that people will tend to assume the worst.
[*] it worked, more or less, for IBM.
Re: (Score:1)
Which leads to the question (Score:5, Insightful)
Re:Which leads to the question (Score:5, Funny)
<IT-EXECUTIVE>
Silly. Microsoft's is the standard implementation. All those other people are incompatible with Microsoft, not the other way around.
</IT-EXECUTIVE>
Re: (Score:3, Insightful)
Interesting, though not necessarily a big change.. (Score:5, Interesting)
For a while now, MS has been the big, bad, expensive monopolist, with *nix and FOSS the freedom loving underdogs; but it should be remembered that MS was once the scrappy, cheap alternative to Big Blue and the proprietary Unix club. In most areas that has changed, since MS has largely taken over and started to tighten the screws; but I suspect that crazy expensive corporate middleware is a fairly conservative market.
This looks more like an alliance of the cheapish, freeish underdogs against the old school proprietary iron guys rather than a change of heart at MS.
Hey, give them time... (Score:3, Interesting)
While "MS Embraces $STANDARD" is certainly rather unusual news (rather, instances of "MS Embraces $STANDARD" that aren't immediately followed by "and Extends" are), I'm not sure that this is actually a big strategic change for MS.
Hey, give them time. They haven't hardly had any time at all to come up with incompatible extensions, they don't even have a product out yet. I'm sure they'll come up with their usual high quality subtle inconsistencies and undocumented XML blobs in no time.
Re: (Score:3, Insightful)
Yep!
They'll come out with the undocumented inconsistencies first, call them features, and the product second!
Re: (Score:3, Interesting)
When was that, exactly?
For file and print services, Netware had NT beaten hands down - for RDBMS, Oracle ran way faster on Netware than on NT, and even the mainframe integration on Netware was light years ahead of the Microsoft offerings.
Novell were just shitty marketers, so Windows (a perfectly adequate desktop OS) ended up competing against real server OSs by default.
OK, the server flavours of Windows are better now than t
Microsoft is changing!! (Score:1)
They even heart PHP! http://www.microsoft.com/uk/servers/winclientshearts/ [microsoft.com]
Next thing you know they will have Django Ponies on their "I'm a PC" commercials. http://djangopony.com/ [djangopony.com]
Re:Interesting, though not necessarily a big chang (Score:2)
"but it should be remembered that MS was once the scrappy, cheap alternative to Big Blue and the proprietary Unix club"
Wby?
Gerry
Re: (Score:3, Interesting)
One might hope that other vendors would use it too, Microsoft may be big but not so big they can break any standard at will. At least in business middleware Microsoft doesn't have a monopoly on vertical will-only-work-with-our-own-products solutions.
Re: (Score:3, Interesting)
XMPP (Score:4, Interesting)
This is the first that I've heard of this technology. Can anyone post how this is different than XMPP (http://xmpp.org)? XMPP is the updated name of the Jabber protocol.
I know that every project that I get on, I try to dissuade the use of JMS (Java Message Service) and use XMPP instead. Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)
Re: (Score:2)
Re:XMPP (Score:5, Insightful)
I try to dissuade the use of JMS (Java Message Service) and use XMPP instead.
Why? JMS is just an API. This is sort of like protesting against POSIX or something. JMS implementations can be open source, commercial, free, expensive, whatever. I'm not sure I see your point, especially since messaging is not a core part of your app, and any sizable business will have an investment in a messaging platform already, in the form of tools, monitoring, expertise, etc.
Is this more of a competitor to the JMS spec, since it "reliable"? (whatever that means)
If you don't know what reliable messaging is, maybe you shouldn't be offering your advice?
Mod parent up - has a clue about the subject (Score:2)
Cause unlike the grandparent poster, he actually has a clue about the subject.
Re:XMPP (Score:5, Informative)
AMQP seems more "enterprisey" than XMPP, focussed on traditional enterprise applications of messaging, XMPP came up from the IM world. This gives them different areas of focus, though they have considerable overlap in functionality. (There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.)
JMS is an API, XMPP is a protocol. There are JMS implementations that can use XMPP as a transport protocol (Apache ActiveMQ, for instance, can use its native OpenWire protocol, STOMP, or XMPP).
"Reliable" messaging usually means that once the messaging system has acknowledged receipt of the message, it has assumed responsibility for guaranteeing delivery to a suitable endpoint (possibly with some caveats). Mostly, it means in practice that the protocol or implementation provides (or, in the case of a protocol, either mandates or supports in a way which permits clients to discover whether the server is using) channels whose contents are persisted to permanent storage before they are acknowledged.
Re: (Score:2)
There are also a number of other protocols in the messaging space: STOMP & Apache ActiveMQ's OpenWire, and most of the big commercial messaging systems use their own proprietary protocols.
That was actually my first thought. What does this do that STOMP doesn't?
Leave it to Microsoft to pick the one I've never heard of...
Re: (Score:3, Informative)
Quite a bit, actually. While its not quite at 1-0 (what every other project in the universe would call "1.0") yet (the most recent release is 0-10), you can look at the high-level requirements list for 1-0 [amqp.org], to get an overview.
Lots of applications probably don't need what it provides over STOMP, either because they don't need it at all, or because they get it somewhere other than the basic messaging protocol, but it certainly covers a l
Re: (Score:1)
Re: (Score:2)
Many systems offer both, but I've seen "Reliable messaging" used for systems that offer persistent channels (usually, though IIRC not always, with transactional messaging, so that multiple interactions with the messaging system itself can be wrapped up in atomic transactions) without support for XA transactions. So I don't really think that XA is key to the general meaning of "re
Re: (Score:3, Informative)
Well, you compare two quite different things (throughput & latency), but I'll bite: You should be able to do 10-100,000 messages per second with Red Hat MRG. If you can't, then there's something wrong with your set up.
Remember that AMQP was initially designed and written by JP Morgan to replace their existing proprietary infrastructure (IBM MQSeries-based IIRC). JP Morgan understand the performance concerns.
Rich.
Re:XMPP (Score:5, Informative)
While XMPP and AMQP do have some similarities, they were developed to solve quite different problems.
XMPP is better for human-to-human or human-to-machine interaction. It is better for federated networks (user@jabber.someserver.com can communicate with user@jabber.someotherserver.com). It has authentication built in. It's more "Internet ready", with modules for BOSH and IRC.
AMQP is geared more towards traditional machine-to-machine message queuing. It offers more control over the type of message delivery ("exactly once", "pubsub", "at least once"). It's aiming to just be a message queue.
RabbitMQ [rabbitmq.com] is an open-source implementation of AMQP built in Erlang. They seem to be quite fond of XMPP, realizing the different natures of the protocols, and even created a module for ejabberd [rabbitmq.com] (also written in Erlang).
Another interesting mashup between RabbitMQ and ejabberd is is a project I stumbled across called Rabbiter [rabbitmq.com], which looks like some sort of implementation of a Twitter-link setup. They're looking to bring CouchDB (also Erlang) in the mix for persistence.
I'm expecting to see quite a bit of interaction between RabbitMQ, ejabberd, and CouchDB over the next few months.
Ruby AMQP Client [github.com]
Python AMQP Client [barryp.org]
Re:XMPP (Score:4, Informative)
This is the first that I've heard of this technology. Can anyone post how this is different than XMPP (http://xmpp.org)?
Here's a post about XMPP vs AMQP by Peter Saint-Andre:
https://stpeter.im/?p=2099 [stpeter.im]
IMNSHO, XMPP (+XEPs) makes AMQP redundant. Although some people might argue that, being a binary protocol, AMQP is faster.
Re: (Score:2)
Thanks for the informative post.
That Microsoft has Embraced AMQP will hasten its demise.
A shame, that. Binary was more efficient. I guess we're still learning from Michael Hart [www.gutenberg.org] that although it's less efficient in the moment, in the fullness of time it's the most efficient.
Re: (Score:2, Insightful)
MQ systems connect multiple programs without having to be constantly connected, and guaranteeing once-and-only-once delivery. Banks use MQ to do data transfers, as they know each item will be delivered once. Also, MQ systems usually allow load balancing (say you have a high speed gateway which pipes messages into an MQ and then several hundred slow-processing clients running the incoming queries, then returning the results back out another queue which the gateway picks up and sends back out via whatever pro
Re:XMPP (Score:5, Informative)
Performance wise, XMPP bills itself as high performance messaging, but the developers are focused on the WAN. AMQP comparatively is ultra-high performance messaging with optimisations for the LAN.
This is confusing as for many projects there is limited need for ultra-high performance data rates. Numbers of the range 100,000 messages per second with latency under one millisecond. At this rate special engineering methods are required, XML, SSL, compression are too slow, focus is upon zero-copy processing, i.e. accessing and updating data in place, because the memory-bus is too slow to perform copies.
There is a discussion between one AMQP and one XMPP developer that sums this up:
http://www.mail-archive.com/jdev@jabber.org/msg19403.html [mail-archive.com]
Another major advantage for AMQP is message routing. You can define which messages are routed to different sites by their content. Again this is an unusual requirement for many projects as they do not exist on such a scale for this to normally be an issue. The closest equivalent is SMTP routing by domain, you can find more discussion on this InfoQ article:
http://www.infoq.com/news/2008/08/amqp-progress [infoq.com]
The main focus on AMQP is to appear a qualified messaging protocol for certified or guaranteed messaging with the necessary tools and support from vendors to promote its usage. XMPP can do a lot of the AMQP functionality already, but most of it is optional functionality rather than a primary design goal. If AMQP support appears in the Visual Studio Development System together with MMC modules for monitoring and administration, for example, its adoption could rapidly grow.
Re: (Score:3, Interesting)
XMPP, despite having originated as an IM protocol, has been used as a transport protocol for more general messaging.
BTDT (Score:2)
NNTP
HTH.
Re: (Score:2)
Not centralized: no single point of failure. That is evidently a required feature of "middleware".
Re: (Score:2)
Very simple; "unload, format, zip, encrypt, sign, post" but worked rather well. However it would be considered a bit slow and unwieldy these days... 3 minutes is too long apparently.
Re: (Score:1)
unload, format,
zip, encrypt,
sign post,
you name it.
This could be a song.
Slashdot is not UTF8 compatible: no â(TM) â(TM) â(TM) here.
What happened to their old product? (Score:4, Informative)
I can't even remember it's name, although it's installed here somewhere.
The IBM MQ product is actually OK to use (very simple, lots of platforms supported) and especially double plus good if you have an IBM mainframe somewhere on your network.
TIBCO? Shudder. About three quarters of the money they charge goes towards getting your manager drunk enough to sign the purchase order. The product itself isn't worth a damn.
Re: (Score:3, Informative)
You mean MSMQ [wikipedia.org]?
Re: (Score:1)
Yeah, that's the one. I assume they will simply gut it and put the new protocol underneath (with a couple of "special" extensions to make it backwards compatible).
Re: (Score:2)
Most likely. MSMQ actually works fine, and its still maintained (that is, they pop out a new version roughly with every version of Windows). Its also what they used under WCF to make for a WS-Reliable (is that the real name? I forget... the OASIS standard along with WS-I basic profile and others) compliant solution. Works decently well, too, and it interoperate quite fine.
Re: (Score:2)
Yes, you can expose your service as WS-RM without it being actually reliable, which achieves pretty much nothing. I understand your point, and I guess my previous post was overly simplistic... but without the MSMQ support, enabling WS-RM is like filling the checklist of Section 508 without having a semantically acceptable page... it will "validate", but still be useless :)
Re: (Score:2)
Re: (Score:1)
Why is Red Hat excited? (Score:4, Interesting)
Perhaps they feel that Microsoft brings recognition to a technology that RedHat is poised to exploit in their products. RedHat is only too happy to compete with Microsoft on an even playing field.
What is this anyway? (Score:2)
OK, I've heard people mentioning messaging and middleware, but what is this exactly? Why would I want to use this instead of XMLRPC or SOAP or something else?
Re: (Score:3, Informative)
Because most competent middlewares supports transaction handling, synchronous and asynchronous, triggering, queueing and prioritizing of messages.
SOAP and XMLRPC doesn't really cut it when you need proper transaction based messaging. I've seen some bastard solutions for this but they perform poorly.
Re: (Score:3, Informative)
Architectures using messaging are more loosely coupled than those using SOAP or XMLRPC. Essentially, every component is a messaging client, asynchronously consuming and/or producing messages that get posted to specified channels. None of the clients need to know anything about any of the other clients, only what types of messages are acceptable to be p
Re:What is this anyway? (Score:5, Informative)
Middleware solutions also come with tools for monitoring, configuring, etc., that simpler solutions often do not. This being said, I've had my fair share of problems with middleware in the past. Like any complex piece of software, you get a lot of functionality, but you also get a lot of baggage and hidden pitfalls that can come back to bite you when your usage of that functionality becomes demanding.
Re: (Score:1)
Typically, commercial middleware vendors don't use the term 'guaranteed delivery', rather something like 'assured delivery'. This is supposedly because of the legal meaning of the term 'guarantee' which vendors are terrified might expose them to litigation if a message fails to be delivered.
Also, internal translation is more often performed on text data than binary - the conversion being between the CCSID of the source platform and the destination platform.
Re: (Score:2)
Re: (Score:3, Informative)
Well, middleware tends to have a bus publish/subscribe architecture. So you throw a whole lot of data onto the bus, and you don't really care where it goes. Clients are clients of the bus, and generally register for data that they're interested in.
The standard example for this kind of stuff is stock trading. Your stock app basically dumps all the transaction information onto the bus in realtime, and clients register for notification of trades on specific ticker symbols or some kind of criteria (>1000 sha
Re:What is this anyway? (Score:5, Informative)
Let's imagine that your organization uses a few different applications. For example a core banking, a loan management, credit card management, call center, billing etc..
Now let's say that you would like to be able to do "fun" stuff when something "cool" happens in one of those applications. For example, when someone default on a loan payment you'd like the core banking to flag the account as "dangerous", block his credit card, cancel his vip status in the CRM, the call center will generate an automated call to connect you to a customer service rep from the debt collection department that will menace you with the word foreclosure.
The first way to do that is to create many one-to-one relationship between all those application. "onpaymentdefaultduedate" in the loan management you could call successively each API of each application to "make it" do whatever it is that needs to be done. So the loan management will need to know about the crm, the call center, the billing etc...
Problem is that the next time you add a fancy new application (SMS harassment gateway for example) or upgrade an existing one (API change yeah!) you'll need to upgrade all the applications that have a one-one relationship. Which mean bringing on board the vendors of each and every applications for top dollars. Plus after a few years, everyone will have forgotten how the things even works. The vendor does not provide version 2 customization and you'll have to upgrade everything to version 7.3.56 and retrain your staff because the interface has changed and you can't expect the tellers to figure it out by themselves.
The second option is to add a middleware that will "sit" in the middle of all your other application (hence "middleware") and connect all the applications together using a publisher/subscriber model.
In that architecture, the loan application does not know about any other application than the MQ. Whenever you start defaulting it will simply send a message ("loandefaulted userid=12 amount=345.5") to the message queue and the MQ will in turn dispatch it to whatever other applications has register an interest for it by saying something like "subscribe to event loandefaulted from loanapplication". Many applications can register to the same event. That way the CRM can flag you, the call center can call you, legal can sue you and the SMS reminder volley can begin. All of that without any applications having to care about the brand or specific implementation (J2EE or
Of course this is a bit simplistic but cover 80% of the purpose of an MQ: loose coupling of application via an event based mechanism. Add to that option such as guaranteed reliability, prioritization of message, security and more complexe workflow of messages with multiple "queries" and "answers" and maybe you'll get a rough idea of why a MQ is a better design that "hard coupling" of n-application (sometime).
Of course since once you've chosen a MQ and adapted all your applications to use it you're basically tied forever and ever to your MQ vendor who hold you by the balls and can continuously rape you over and over with astronomical maintenance fee since you now have a single coordinated point of failure that can and will eventually take everything down at some point.
But hey, you're a big bank you can take it.. or at least you could until a month ago but whatever...
Clearer?
Re: (Score:2)
Yeah, but what you've just described in BizTalk... only that's not quite the fire-and-forget applicationinfrastructureframework that it should be.
So, perhaps we'll see it integrated into that, just so you can be enticed by the 'open and interoperable' MQs but then get bent over the totally un-open and expensive Biztalk server while .. you described the rest already.
Re: (Score:2)
While it's still in incubation, Apache's qpid [apache.org], might be worth a look. If it sucks now, throw a developer to help with it, and you'll have a sust
Re: (Score:2)
Bad form, perhaps, to reply twice, but for more information on what messaging is, a decent starting point is the Enterprise Integration Patterns [eaipatterns.com] website.
Re: (Score:2)
Not at all. Thank you (and everyone else!) for a good primer on the subject.
Sooo.... (Score:1)
Re: (Score:2)
What was your point?
Re: (Score:2, Informative)
And you get C# which is actually a much nicer language than J++ ever was, integrate way better with Microsoft platform
Microsoft took Java, did a shitty job at writing a VM for it, ignored repeated urgings to conform, then threw a tantrum and reinvented the wheel.
... gave a much needed kick in sun's behind who realized it was finally time to update Java with some interesting features. Both are now alive and kicking.
Competition's always better, and my point wasn't to compare Java and C#. It was to demonstrate Microsoft's approach to such issues, which is to dissect, then "reinvent".
What was your point?
Pay better attention next time
Re: (Score:2)
did a shitty job at writing a VM for it
Call it a conspiracy theory, but I always figured that fragmenting Java was the whole point...Sun came up with WORA, and Microsoft tried for a while to make sure that "anywhere" did not include their platform. And got away with it for a while.
TIBOC Rendezvous vs. SmartSockets? (Score:2)
What are the differences between TIBCO SmartSockets and Rendezvous? They seem to be very similar. I suppose I could try reading the documentation for Rendezvous, but I know someone out there in /.-land knows the information already and is itching to share!
I use SmartSockets indirectly through a secondary API in some software that I maintain. The secondary API, GMSEC [nasa.gov], is meant to provide a standard interface to the messaging layer; i.e. so that no matter what MOM you want to use, your programs use the sam
Re: (Score:1)
SMTP analogue? (Score:5, Insightful)
Suffice it is to say that AMQP is to high-value, reliable business messaging what SMTP is to e-mail.
So it sort-of works but it's 30 years out of date and every man and his dog has a different opinion as to how to fix its gaping flaws?
Re: (Score:1, Interesting)
A few years ago I had a look at a very early draft of AMQP. Although I did spot (and report) some potential problems in the draft specification, there was one aspect I did like a lot: the authors had taken Moore's Law into account. For example, some of today's middleware protocols place a unique RequestId n the header of messages. When a protocol does that, the protocol desig
Re: (Score:1)
Can you point me to the source code of the original wheel?
Re: (Score:2)
Will this replace MSMQ? (Score:2)
And will Microsoft finally have a publish-subscribe message queuing system as a result?
Chip H.
Not so little known (Score:4, Informative)
Odd this came up just at this moment, though it's hardly little known.
Implementations:
Several here: http://jira.amqp.org/confluence/display/AMQP/AMQP+Products [amqp.org]
ActiveMQ: FOSS Messaging Middleware (Score:2)
There are also F/OSS MOM products (Apache ActiveMQ, for one) that do not operate "exclusively in single-vendor fashion" (ActiveMQ can "talk" STOMP and XMPP, as well as its native protocol,
AMQP for Beginners (Score:3, Interesting)
Here's a real-world application for AMQP.
Let's say there are two banks, BA and WTF. Every day they have debits and credits flying back and forth.
A protocol like AMQP makes exchanging messages (aka transaction) robust. Bank's IT guy gets mad and pulls the T1 out the wall at BA? Messages do a few things like wait in a queue at BA.
The messages that were sent to WTF before the cable was pulled were processed by WTF and wait in a queue at WTF unti BA comes back online.
That's a simple example. There is lots of information outside of the banking world where robust messaging is required.
Embrace, extend... (Score:2)
.
Those who do not know history are doomed to repeat it.
Re: (Score:1)
Those who do not know history are doomed to repeat it.
The most common lesson we learn from history is that we don't learn from history.
Speaking of standards (Score:4, Insightful)
Speaking of standards...
We should establish, as a standard, an enumerated list of the half-dozen or so stock Microsoft whinges that end up as eighty percent or so of the comments to any article that mentions Microsoft.
Instead of typing it fresh each time, or pasting it from a previous message, the poster could just invoke e.g. "#3", instead of "Microsoft will Embrace, Extend, Extinguish" and all its semantic equivalents.
Better yet, since the list will be pretty short, the Slashdot UI could be modified to include a drop-down list of the standard whinges with any article that includes the Microsoft name. Select a whinge, and Slashdot automatically posts a comment for you (correctly spelled). What could be simpler?
The aggregate time savings would be a major boon to the American economy.
Re: (Score:2)
You're being funny, but I am slowly building a little page for my eternally-PreAlpha site that charts all three-five steps of the lifecycle of various announcements. Each time we try to be future-looking and says "E-E-E was all in the past", only to see fresh examples. OOXML was the one that really slammed home for me.
Re: (Score:2)
Like the old joke about prison inmates shouting numbers because they've all heard everyone's jokes so many times, and then the new guy stands up and says a number, but no one laughs because apparently he's not good at telling jokes.
(I am not good at telling jokes, look what I did with that one :D )
Sounds like a GreaseMonkey script in the making... (Score:1)
Nothing like it exists yet... http://userscripts.org/tags/slashdot [userscripts.org]
The words ring hollow (Score:3, Informative)
"They are also -- perhaps not by coincidence -- burdensomely expensive."
I've been using Exchange since 5.5 and have dealt with every revision up to the current one. When the organization that I worked for developed a need for in house IM the first place I went to look was Exchange. They had built in IM in Exchange Server 2000. We're running 2003 and surprise, surprise... IM is gone. Now Microsoft expects us to purchase some Office Communications Server or some BS like that to have the functionality that was previously free.
Given that experience with Microsoft and IM, I don't think that they're really in the business of giving free functionality to people using their software.
As long as I'm posting this, can anyone recommend some good, hopefully free IM clients for internal use? We only need to support about 50 users.
Different kind of messaging (Score:2)
Business messaging is about the assured transfer of data using FTP or other transfer protocols, not email over SMTP or MAPI. It's done using queues and management systems to route, deliver and confirm that data has been delivered in a auditable way. Funnily enough it has more in common with instant messaging than it does with email.
On the subject of IM, you could do worse than find a decent but surplus PC, install VMWare Server on it and get a Jabber server appliance. Jabber and XMPP is an excellent alterna
Re: (Score:1)
"Openfire (formerly Wildfire) is a cross-platform real-time collaboration server based on the XMPP (Jabber) protocol."
Re: (Score:2)
I've yet to set one up so I can't offer you any advice based on first-hand experience. But I can tell you that you need to decide if it will be internally hosted or not. It sounds like that's what you're getting at anyway. Maybe check out Openfire (used to be Wildfire)? Java-based. Integrates with AD. I have it on the back burner as something to check out for my own users.
Re: (Score:2)
Yeah, use winpopup for IM, that was around in 3.11 for workgroups.
standards (Score:1)
Defacto standard! (Score:3, Interesting)
The defacto standard in this area is Webshere MQ from IBM.
It has something like 90% of the business relaible messaging market.
All the other commercial products (MSMQ, Oracle, Tibco etc.) are niche players.
MA is actually pretty cheap for a "Websphere" branded product starting from free for a
try this at home folks windows installation, through a few $,000 dollars for a sizeable unix
shop license to tens of thousands for a mainframe setup (This IS considered cheap for mainframe software!)
If you can persuade your boss not to pay for software (always desparately hard in a business environment!) then ActiveMQ is the defacto standard for open source implementations. AFIK its just as good as IBMs product as long as you stay in the Java world.
This all looks like an attempt to cause confusion and muddy the waters with yet another unstandard standard.
Re: (Score:2)
While Microsoft's involvement may be about muddying the waters, the AMQP effort itself seems to be about actually having a standard enterprise messaging protocol: the main standard in the messaging space is XMPP, and it wasn't designed around enterprise needs (one might argue that in the long term, it would be better to adopt and/or extend XMPP, or that if you were going to design from the ground up A
A very fast messages broker (Score:2)
If you are looking for a very fast messages broker, have a look at the ZeroMQ project : http://www.zeromq.com/ [zeromq.com]
Although it looks not a lot of people have heard about it, and although AMQP is still on the todo-list, it's free, open-source and it works damn well.
Regardless of the API and protocol, messages brokers are very helpful to build horizontally scalable applications.
Re: (Score:2)
Before someone nitpicks: ZeroMQ is not really a messages broker, messages are directly sent to the recipient without passing through any broker and this is what makes ZeroMQ different and fast. But the end result is that you get the same features as a messages broker, just faster and easier.
ZeroMQ is still under development though. But it really needs more exposure.
Re: (Score:3, Interesting)
Except, no, you don't get the features of a message broker. Particularly, you don't get reliable messaging. Its not really all that surprising that when you take the "middle" out of "middleware", you get a speed increase, at the same time losin
Why AMQP is important and how to use it (Score:3, Informative)
I work on RabbitMQ which is a messaging implementation that provides AMQP and other patterns. I hope my comment here can clear up some misunderstandings in the community.
Here is an introduction to AMQP from the RabbitMQ team - there are two presentations and a video - made at Google a few weeks ago: http://google-ukdev.blogspot.com/2008/09/rabbitmq-tech-talk-at-google-london.html [blogspot.com]
People who are wondering why AMQP is important compared to MQ, JMS, or whatever, should check out the first presentation. The second presentation includes information about XMPP vs AMQP. The two protocols are strongly complementary and are not alternatives. You can use these today: RabbitMQ as someone mentioned above has clients in lots of languages like Java, Ruby, Python,
Integration with Visual Studio has been done: http://www.rabbitmq.com/dotnet.html [rabbitmq.com]
As someone else pointed out there are protocol adaptors including STOMP and XMPP: http://www.lshift.net/blog/2008/07/01/rabbitmq-xmpp-gateway-released [lshift.net]
It is open source - we welcome questions on the mailing list which you can find linked to from the home page: http://www.rabbitmq.com/ [rabbitmq.com]
Cheers,
alexis
Mods on crack (Score:1)
And I have karma to burn.
Parent is not "off topic"