Weekly Edition
Return to the Press page
| |||||||||||||
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal)
Tina Gasperson
looks at
the Mule
project on IT Manager's Journal.
"Mule is an Enterprise Service Bus (ESB) -- the "glue" between different enterprise applications in different company departments that allows IT managers to move information back and forth seamlessly. Think of disparate enterprise applications as ribs, with the ESB as a backbone that connects everything. Mulesource founder Ross Mason says open source is the best way to make an ESB that is customizable and affordable.
In 2000, Mason was working on a large-scale project for a bank. He found himself growing tired of the endless repetitive coding tasks that were necessary to tie disparate applications together for in-house ESBs, calling it "donkey work.""
(Log in to post comments)
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 12, 2007 21:41 UTC (Thu) by ajross (subscriber, #4563) [Link] I, uh, can't parse that. The metaphor to fact ratio is just too high. Can someone translate?
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 12, 2007 22:06 UTC (Thu) by drag (subscriber, #31333) [Link] I took a look at it and here is my attempt at understanding it...
Think of this like 'dbus', but instead of relaying desktop notifications around it is designed for enterprise-sized notification networks.
Their special thing is that it allows you to take a bunch of existing unrelated software/services/applications all using different protocols and mechanisms for relaying information and use Mule to develop a way to allow them to communicate with each other and provide ways of consolidating information for IT folks.
This is in contrast, so they claim, to other competeting propriatory software that demands that all the applicatiosn need to support _their_ way of communication.
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 0:00 UTC (Fri) by dskoll (subscriber, #1630) [Link] Huh. We use an IRC server for this, with a bunch of special IRC channels in which events are dumped. And then some bots coded in Perl react to the IRC messages.
Dead simple and it works really well. Unfortunately, it's very low on buzzword compliance.
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 0:54 UTC (Fri) by drag (subscriber, #31333) [Link] Also I bet your not selling it as a backbone to a Enterprise infrastructure either.
Maybe you should?
:-P
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 2:37 UTC (Fri) by dskoll (subscriber, #1630) [Link] Also I bet your not selling it as a backbone to a Enterprise infrastructure either. Good guess! Maybe you should? Ewww... to sell it, we'd have to work in Java, which as any PHB knows is much more suitable than Perl for being the "glue" that links "disparate enterprise applications".
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 4:45 UTC (Fri) by lacostej (guest, #2760) [Link] IRC: nice !
How does that scale with regard to distribute big deployement ? Do you need multiple servers? (just curious)
(hope I got it right)
The nice part of Mule is that it abstracts the transportation protocol and make it very easy to plug in into your existing application, without forcing you to adapt to a particular mean of communication.
So in your particular case, your application connects to IRC (directly or through your perl bot)?
Implementing this with Mule would require you to write a connector that you would plug into Mule, not into the app, then you would configure Mule to choose the end point and to use a particular transport to send the message. Not sure if there's an IRC transport but that could maybe be an implementation.
So I guess IRC is OK when you control all parts of the deployment, but in some cases, you don't and mule may help. Also if IRC works today, maybe it won't in the future, in which case you have to update all apps. With mule you would just change the transport mechanism configuration.
IRC requires centralization through a server, while Mule doesn't.
Mule also allows you to directly connect your app when needed. So if you change your deployment scenario, you just change the configurations that connect the relevant applications.
(I hope I got it right :)
What do you think ?
See also http://today.java.net/pub/a/today/2005/10/18/service-prov...
See http://mule.mulesource.org/display/MULE/Hello+World+Example as a simple example
Mule is one of the nicest project in the Enterprise Java OSS world. And Ross is a nice guy to take a beer with (I met him several years ago when he was starting his project) :)
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 14:18 UTC (Fri) by drag (subscriber, #31333) [Link] > How does that scale with regard to distribute big deployement ?
I would expect that it scales very well.
This IRC control technique is how people control massive amounts computers in illegal botnets.
They'd find a Linux server (or similar) somewhere with a good pipe and bad administrator, hack it, install their rootkits and IRC servers to remotely manage their Windows-based botnets.
They'd setup a IRC bot as a sort of ringleader on that server.
Then they'd modify some old worm using some Windows exploit.
As the worm roams around the internet, the infected machines then seek out the IRC server, or one of it's mirrors, to get instructions.
The ringleader IRC bot would then provide uploads or additional instructions for those hacked machines.
Then when the script kiddie sells off the botnet or rents out it's services all they have to do is log into their illegal IRC server, update the ringleader bot with new instructions. The Windows-based rootkits check in, upload the new spammer email program or whatever and then they are off spamming massive amounts of email.
So over the internet this sort of thing easily scales to thousands of clients. Tens of thousands or maybe even hundreds. Who knows.
This is just what I understand personally about it, details probably differ from realities, but I don't think it's far off.
It's the first thing that jumped into my head when the other person mentioned they used IRC to coordinate stuff. (maybe some of the lead IT folks wore darker hats in their previous lives, eh?)
From what I understand this is getting less popular. It's to easy to detect IRC servers. Nowadays people use encryption and such that runs over highjacked Apache servers or something like that. Run the botnet herding it over http or https ports and have it encrypted. It's not unusual to have encrypted web traffic, so the illicit activities are harder to notice. Plus most people already have holes punched through their firewalls for web servers and such. But I can see how this would be handy for administrators.
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 20:58 UTC (Fri) by dskoll (subscriber, #1630) [Link] How does that [IRC] scale with regard to distribute big deployement? Honestly, I have no idea. We're a pretty small company. However, as another poster pointed out, IRC is used as a control mechanism for tens of thousands of zombie PCs, so my guess is it could be made to scale very well. So in your particular case, your application connects to IRC (directly or through your perl bot)? Sometimes directly, but more often the perl bot reacts to the IRC message and does something to control the application, where "something" means to take some application-dependent action. IRC requires centralization through a server, while Mule doesn't. Well, IRC is just one example; we used it because it was trivial to implement. One can easily envision a P2P network doing much the same thing. Regards, David.
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 5:58 UTC (Fri) by k8to (subscriber, #15413) [Link] Hmm, how do you deal with the lack of flow control in irc? That is, the usual ircd's approach to input is to use a fixed size queue for each client, which when overflowed causes the link to be dropped. Did you modify your ircds to handle the maximum forseeable datarate, did you add flow control, or have you not encountered this snag yet?
IM as glue Posted Apr 13, 2007 12:23 UTC (Fri) by qu1j0t3 (guest, #25786) [Link] Good simple solution. Jabber is designed to work even better for this.
IM as glue Posted Apr 13, 2007 20:23 UTC (Fri) by muwlgr (guest, #35359) [Link] Good old e-mail is a rock-solid "bus" eatsblished long, long ago.It is pretty instant/realtime in fast local networks, it has addressing that allows global-scale interaction&integration, it has queueing/retrying/multipleMX facilities for fault tolerance, it can even pass messages over non-IP networks (like uucp). smtp+pop3/imap, that's it. Just know it and use it.
I could hardly understand why there was a need to invent "XMPP" and the like,
IM as glue Posted Apr 13, 2007 20:27 UTC (Fri) by muwlgr (guest, #35359) [Link] And yes, you have e-mail libraries/bindings/APIs for most of existing programmable systems. And yes, it does not require Java as well as XML. Are you still not bought into this idea ? :>
IM as glue Posted Apr 14, 2007 14:21 UTC (Sat) by qu1j0t3 (guest, #25786) [Link] Java has nothing to do with XMPP.
IM as glue Posted Apr 15, 2007 11:04 UTC (Sun) by muwlgr (guest, #35359) [Link] I did not state the contrary.The original topic was about Mule ESB which requires both Java and XML if I understand them right.
IM as glue Posted Apr 14, 2007 11:18 UTC (Sat) by man_ls (subscriber, #15091) [Link] E-mail and IRC are very good protocols, but unfortunately they are already in use for other purposes. Many companies have already deployed products that manage e-mail and sometimes IRC; besides, they may feel uneasy letting IRC traffic go through their networks.
IM as glue Posted Apr 15, 2007 11:14 UTC (Sun) by muwlgr (guest, #35359) [Link] Yes, IRC not. It looks too hackerish. But why not email ?I am sure that this Mule ESB brings with it the whole suite of self-invented naming/addressing conventions and directories, as well as transport&exchange protocols. It should be well evaluated and weighted, whether Mule ESB really adds an useful layer of indirection, or just brings more complexity to the existing system which in most cases desperately cries for simplification.
IM as glue Posted Apr 15, 2007 11:50 UTC (Sun) by man_ls (subscriber, #15091) [Link] But why not email ?To put it bluntly, because it is very possible that the company already has a crappy proprietary mess of a program managing email, be it Microsoft Exchange or Lotus Domino or whatever, and it will usually be quite difficult to make it talk to the rest of our middleware. Also, email outages of several minutes or even hours are perfectly acceptable within a company's infrastructure. Would you bet your messaging framework (and your whole operations) on that? Would you rely on email for a flux of some hundreds of *critical* messages per second? Probably not. Typically you will need different channels for that; you can painstakingly design a different and custom infrastructure for each level, or you can just configure an ESB and forget about it.
IM as glue Posted Apr 16, 2007 9:09 UTC (Mon) by muwlgr (guest, #35359) [Link] I don't think ESB computing elements are in any way more stable and reliable than email ones. They both are just software, developed by mortal people and running on the top of another software (Java, underlying OS) so I would not expect to find any magic inside of ESB which is not found in email soft.
IM as glue Posted Apr 16, 2007 9:19 UTC (Mon) by man_ls (subscriber, #15091) [Link] Sometimes protocols matter too. Internet mail was never designed to support sending and receiving thousands of messages per second; JMS was. Combine this with the ability to use different channels depending on availability, and the result is much more scalable than the alternatives.
IM as glue Posted Apr 16, 2007 12:18 UTC (Mon) by muwlgr (guest, #35359) [Link] Hope you would not argue that modern J2EE programming is a real torture, both for human psychics and for hardware. I have concluded long ago that J2EE programmers are paid higher than usual not for their highly-demanded skills, but for their ability to tolerate suffering :>
Remove Java (and XML) from the whole system, and you'll make it much leaner and simpler, and your people well happier >:
alternatives to J2EE Posted Apr 16, 2007 12:36 UTC (Mon) by qu1j0t3 (guest, #25786) [Link] What would you replace it with? (sorry, .NET is just not a serious contender - maybe it works technically, but its nonportable/proprietary/deliberate lockin issues are fatal)
alternatives to J2EE Posted Apr 16, 2007 13:37 UTC (Mon) by man_ls (subscriber, #15091) [Link] What muwlgr does not seem to realize is that Java and XML do not replace platoons of happy Python or Lisp hackers, but scores of mossy COBOL programmer-analysts (or, god forbid, hordes of Visual Basic drones). Strongly typed object-oriented languages used in multi-layered programs are not a fancy, they are a necessity in complex business applications.Similarly, business applications do not use readable text files for configuration; that is the realm of hackers (bien entendu). XML comes to replace inescrutable undocumented binary formats. Maybe it can be done with Perl scripts, C libraries and rc files, but the fact is that it is not commonly done. I do not advocate doing things this way: I would be happy developing web applications in Python. But the fact is that Sun (with IBM) has stroken a chord within the business community with Java, which other languages have not; and now customers are requesting XML where before they were happy with binary blobs. If you want to sell your stuff do not dismiss those who are successful doing exactly that; learn from them and know your audience.
alternatives to J2EE Posted Apr 16, 2007 18:03 UTC (Mon) by dskoll (subscriber, #1630) [Link] What would you replace it with? Perl Perl was explicitly designed to be a "glue" language to hook together disparate apps, and it excels at that. It's cross-platform (Mac/*NIX/Win) and has a huge library of available modules. Perl lacks Sun's marketing and the (IMO stupid) "Enterprise" moniker, though, and that handicaps it severely among PHBs.
alternatives to J2EE Posted Apr 16, 2007 18:18 UTC (Mon) by qu1j0t3 (guest, #25786) [Link] Perl's great, I like and use it myself. Perl 6 will be at least six times better.
I'll reserve judgment on whether Perl is a feasible substitute for the Java platform, in all cases, however.
alternatives to J2EE Posted Apr 16, 2007 19:41 UTC (Mon) by dskoll (subscriber, #1630) [Link] I'll reserve judgment on whether Perl is a feasible substitute for the Java platform, in all cases, however. If you want to impress non-technical people and/or lemmings with your resume, and you want to say the right buzzwords at an "Enterprise" interview, Java is way better than Perl. If you want to actually get stuff done, on the other hand... Paul Graham has an interesting essay on this topic: http://www.paulgraham.com/icad.html
alternatives to J2EE Posted Apr 16, 2007 20:04 UTC (Mon) by man_ls (subscriber, #15091) [Link] If you want to impress your hacker friends, and say the right buzzwords at a Linux conference, Perl is the way to go. If, however, you want to build a big business application you would do well to think it twice.Some time ago I was looking for big software packages for a certain study. When I tried to find a really big Perl package (more than one million lines), I found none. First I thought that I didn't know the language that well; after all CPAN is one of the biggest public code repositories out there, but I was looking for a program, not a library. Now I think there may be a reason there are no big development efforts in Perl. (For reference, Slashcode is 95k lines.) I would be glad if you proved me wrong here. I didn't find anything that big either for Python; but Python is relatively new. On the other hand, Java, C++ and C -- there you can have your day. You can argue that one line of Perl is much more productive than one line of Java; however functional metrics say otherwise. It is interesting that you quote Paul Graham; as he himself stated, he never tried to hire Lisp programmers for his company. Well, that is OK if you are the owner; but if you are planning on building a large project you should plan on hiring somebody. I'm sure you have heard about software engineering and heroic efforts. There's a reason Perl has been called "the duct tape that holds the internet together". Building a bridge out of duct tape is generally considered a bad idea.
alternatives to J2EE Posted Apr 16, 2007 20:27 UTC (Mon) by dskoll (subscriber, #1630) [Link] Some time ago I was looking for big software packages for a certain study. When I tried to find a really big Perl package (more than one million lines), I found none. But we aren't talking about big million-line-plus packages... we're talking about gluing disparate (and typically, uncooperative) applications together, which is what Perl was designed to do. I have written largish programs (one > 300K lines and another > 700K lines), but that was in C++ and it's a whole different story.
alternatives to J2EE Posted Apr 16, 2007 21:45 UTC (Mon) by man_ls (subscriber, #15091) [Link] But we aren't talking about big million-line-plus packages... we're talking about gluing disparate (and typically, uncooperative) applications together, which is what Perl was designed to do.I'm afraid that the thread has drifted a little bit from that; a few comments above, muwlgr was asking us to Remove Java (and XML) from the whole system [...]and qu1j0t3 answered to that. Anyway, Mule is not a custom glue layer; it is a generic, highly configurable 200k lines Java package. (Not 1M lines but getting there it seems.) Take a look at the things you can glue together out of the box.
alternatives to J2EE Posted Apr 17, 2007 15:01 UTC (Tue) by dskoll (subscriber, #1630) [Link] Anyway, Mule is not a custom glue layer; it is a generic, highly configurable 200k lines Java package. I'm sorry... it just seems wrong. You basically spend 200K lines of Java to get... a system you "program" using XML. All of your customization scripts end up being equivalent to little snippets of Perl glue, except they're XML and required re-invention of 200K lines of Java to interpret them.
alternatives to J2EE Posted Apr 17, 2007 20:45 UTC (Tue) by man_ls (subscriber, #15091) [Link] OK, I see your point. But see it from a different point of view: you already have the custom snippets of Perl glue all around, difficult to change or even know how many there are; essentially you have the same copy-pasted all around, so each time you change something in one place, it breaks in another. The resulting system is extremely brittle and unstable.Now you can choose a program where from a single configuration file you can control almost all of your infrastructure; to change an endpoint or a transport you just have to change the file. Replacing your whole setup (programs, endpoints) with another one now looks almost doable, and probably is, with time and care. It is all about manageability, and managers love that :D
alternatives to J2EE Posted Apr 19, 2007 1:41 UTC (Thu) by dskoll (subscriber, #1630) [Link] you already have the custom snippets of Perl glue all around, difficult to change or even know how many there are; essentially you have the same copy-pasted all around, so each time you change something in one place, it breaks in another. The resulting system is extremely brittle and unstable. Ummm... speak for yourself. I have properly-written Perl modules with actual POD documentation, all in logically-organized SVN repositories. Just because you can write crappy Perl doesn't mean you have to. An undisciplined sysadmin will screw up MULE configuration just as surely as he/she will screw up scripting, and a disciplined one will probably do well with both systems.
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 15:31 UTC (Fri) by nim-nim (subscriber, #34454) [Link] A real ESB is much more than a notification network.Common W3C wisdom is to have a dumb network and smart endpoints
In an entreprise context you have a pile of endpoints which are not going smarter any time soon (legacy systems, of-the-shelf systems you can't modify, critical don't-you-dare-touch-it systems, in-house stuff that does FTP because it has "File transfer" in its name, etc). They all exchange data. It's a costly mess (as in spaguetti + local fiefdoms + heterogeneous tech)
So you put the smartness where you can, in the network. You tell every endpoint to plug its data interfaces (imports, exports, messages, whatever) in a smart hub (or a serie of chained smart hubs). When you need to reconfigure your information system you only need to reprogram this hub (and not locate all the entities needed to change every single endpoint)
The old craze was EAI (I try to speak every possible protocol but I'm real bad at changing flow logic). The new one is ESB (I'm real good at flow logic but don't ask me to speak your weird protocol, I only talk HTTP, SOAP & JMS)
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) Posted Apr 13, 2007 13:46 UTC (Fri) by ballombe (subscriber, #9523) [Link] ESB means "mad cow disease" (BSE) in French. Probably a mad cow that has a delusion of being a donkey. Thus "the mule take the donkey out of the mad cow" make perfect sense.
Not open source Posted Apr 13, 2007 4:02 UTC (Fri) by rickmoen (subscriber, #6943) [Link] As a correction to the article: Mule is not open source. It is under a modified form of MPL 1.1 with a proprietary addendum impairing third-party commercial usage. The firm has refused to submit its licence to OSI for certification (for the obvious reason that it would be declined for reason of multiple OSD violations).
Rick Moen
Not open source Posted Apr 13, 2007 5:13 UTC (Fri) by lacostej (guest, #2760) [Link] I wasn't aware of the issue. Some more info: http://weblog.infoworld.com/openresource/archives/2007/01...
Not open source Posted Apr 13, 2007 17:04 UTC (Fri) by Ac (guest, #44650) [Link] Maybe I'm missing something here.
I went to the mulesource web site and read the license and I don't see anything restricting commercial use. For some reason they define the term "Commercial Use" to mean "distribution or otherwise making the Covered Code available to a third party", but that term is only used once in the license that I found and has to do with when contributor rights are effective.
Perhaps they have modified the license recently? The version I saw was 1.1.4.
Not open source Posted Apr 13, 2007 17:45 UTC (Fri) by rickmoen (subscriber, #6943) [Link] "Ac", please read Exhibit B on the licence. Requiring commercial users to use a trademarked logo and name, while simultaneously specifically denying them any licence to those trademarks, creates a trademark legal threat overshadowing such usage. (Some would argue that the requirement creates an implied trademark licence, but the point is unclear, and meanwhile that uncertainty deters commercial competition, whether so intended or not.)
Version 1.1.4 of the licence is actually radically better, in this area, than its predecessors: The earlier versions required you to have a specific-sized logo, name, and linkback display on "every user interface screen".
Rick Moen
Not open source Posted Apr 13, 2007 19:19 UTC (Fri) by Ac (guest, #44650) [Link] Oh yeah, I had noticed but sort of ignored that contradiction assuming that the requirement explicitly gave the needed "permission", but you're right, in a business setting, this kind of ambiguity is a red flag.
Maybe they should take another whack at it to word that part more carefully. Time spent getting the wording exactly right is well worth it later on. It's still my impression that they don't intend to restrict commercial usage.
Thanks for the clarification.
Not open source Posted Apr 14, 2007 0:02 UTC (Sat) by rickmoen (subscriber, #6943) [Link] Ac, you're welcome.
OSI former chief counsel Larry Rosen has also pointed out a serious gotcha that should motivate firms to eschew such language: Trademark owners have a legal obligation to licence the marks only with adequate quality control or supervision (see, for USA jurisdictions: Dawn Donut Co. v. Hart's Food Stores, Inc., 2nd Circuit, 1959). The courts have held that such failure to exercise control substantively constitutes "abandonment" of the trademark, which can lead to the mark's cancellation by (in USA) the USPTO or by judges.
When a licence like MuleSource's says that everyone must use their mark, they're automatically failing that test, and risk losing the entire trademark property.
Larry has pointed out that pitfall twice, in related discussion on the OSI license-discuss mailing list. So far, firms like MuleSource aren't heeding his warning.
Rick Moen
|
|||||||||||||