Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal)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)In reply to: Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal) by drag Parent article: Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal)
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.
(Log in to post comments)
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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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 (subscriber, #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.
|
|||||||||||