Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
|
| |||||||||||
IM as glueIM as gluePosted Apr 13, 2007 20:23 UTC (Fri) by muwlgr (guest, #35359)In reply to: IM as glue by qu1j0t3 Parent article: Open source Mule takes the "donkey work" out of ESB (IT Manager's Journal)
Good old e-mail is a rock-solid "bus" eatsblished long, long ago.
I could hardly understand why there was a need to invent "XMPP" and the like,
(Log in to post comments)
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.
|
|||||||||||