Posted Apr 13, 2007 4:45 UTC (Fri) by lacostej (subscriber, #2760) 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.
What is Mule ESB? Mule, the runtime engine of Anypoint Platform, is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data.
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 See 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):). Posted Apr 13, 2007 14:18 UTC (Fri) by drag (subscriber, #31333) 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.
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. Posted Apr 13, 2007 20:58 UTC (Fri) by dskoll (subscriber, #1630) 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. Posted Apr 13, 2007 20:23 UTC (Fri) by muwlgr (guest, #35359) Good old e-mail is a rock-solid 'bus' eatsblished long, long ago.
Mule Esb Alternatives For Mac Download
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, let alone those 'ESB's. Posted Apr 15, 2007 11:14 UTC (Sun) by muwlgr (guest, #35359) 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. Posted Apr 15, 2007 11:50 UTC (Sun) by manls (guest, #15091) 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.
Posted Apr 16, 2007 13:37 UTC (Mon) by manls (guest, #15091) 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. Posted Apr 16, 2007 20:04 UTC (Mon) by manls (guest, #15091) 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 say otherwise. It is interesting that you quote Paul Graham; as he himself stated, he never tried to hire Lisp programmers for his company.
Mule Esb Java
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. Posted Apr 16, 2007 20:27 UTC (Mon) by dskoll (subscriber, #1630) 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.
Posted Apr 16, 2007 21:45 UTC (Mon) by manls (guest, #15091) 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.) at the things you can glue together out of the box. Posted Apr 17, 2007 20:45 UTC (Tue) by manls (guest, #15091) 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. Posted Apr 19, 2007 1:41 UTC (Thu) by dskoll (subscriber, #1630) 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. 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.