Please create an account to participate in the Slashdot moderation system


Forgot your password?
The Almighty Buck

Open Source Banking 79

Cynical Yorkshireman writes "I sold my soul to investment banking a long time ago ... It's nice to know that some of the Wall Street money machines are actually quite forward thinking about IT! Dresdner Kleinwort Wasserstein will announce today that (with's help) that they are open-sourcing their internal systems integration toolkit. The official launch is today. Until recently I actually worked at DrKW, and have used this stuff a heck of a lot over the years. Basically, this is a toolkit that allows disparate systems to be connected (Sybase->RV->JMS->IIOP->ETX->MQ->UDB is a snap) in a very, very easy way. Without doubt one of the best pieces of software I have ever seen, and far and away the most useful! Go get it (when the site opens), and never worry about system interfacing again ..." There's also a Reuters story with more information. Note that is still password-protected as I write this.
This discussion has been archived. No new comments can be posted.

Open Source Banking

Comments Filter:
  • It does use XML. Look at the website using guest/guest.

    Oh. Thanks. Where did you get the username and password? Random guess?


  • by Alien54 ( 180860 ) on Tuesday January 30, 2001 @06:20AM (#470695) Journal
    This will really test a person's core belief in the principles of Open Source.

    Basically, do you believe (or whatever) in Open Source enough to bet your bank account on it?

    Would you download the source code and inspect it first? or who would you look to, to validate and verify that the code was clean?

    after all, it is only your money.

  • Nice to see that Europe is leading the way on this. After all, Dresdner is based in Frankfurt and London...
    Makes a nice change from all the Amerocentric stuff...

    Hacker: A criminal who breaks into computer systems
  • Well I know for a fact that several large US banking organazations do use Free software here and there, and I know that Euro cutover in the City of London used perl in a heavy way.

    Now that being said I would imagine that much of what runs inside a bank is big iron from IBM with a big 4 database on it. But IBM has embraced Linux and free software. And a lot of it is custom I would guess.
  • Open source Banking FAQ :

    Q1 : Would you trust your money to an open-source bank ?

    A1 : No.

    Hell, I hate banks : they always display the most astounding financial results, while complaining about the economy and laying off as much people as they can.

    Do you really think that they will open-source their inner systems : unlikely. Firstly because they largely prefer security by obscurity, and secondly because I doubt the open source community will manage to do something usefull with their base of mainframe-based COBOL code. Sure, their web infrastructure will be all unix/win as it can be, but the account will reside on some real safe system.

    But as for their integration software, as they pointed into the article, that will be profitable for them and their clients to have that part of the code improved by the global community : that's just another way of drawing on the global ressources.

    Worst, they might just tell their clients : our integration software is open sourced, hire some hacker and do not bother us again.
  • ``Face it, bankers are old fashioned and play things in a very old school manor.''

    No argument there. My experience in the banking industry (well, the bond trading part of it) as well as (a small) credit card processing company was that they tended to lean toward ``trailing edge'' technology since it was tried and true.

    ``With Open Source project management practices being as bad as they are and with the open source evangelists and advocates screaming and preaching that open source is ?shareware?''

    What OSS ``evangelists'' are screaming that it's shareware? Never heard any myself. Shareware has a certain meaning that most OSS advocates that I know don't find particularly applicable to most OSS.

    And regarding ``Open Source project management practices being as bad as they are...'': my experience was that project management in the banking industry was no better (and IMHO, actually worse) than other industries and from what I gather the OSS development process. It seemed to be more politically driven than I'd ever seen before... or since. I spent a lot of late nights fixing problems that these development processes produced. Amazing how many vice presidents were calling me at 11:30 P.M. asking for help getting their crappy software kludges to work or backing it out since it was never going to work that night. I worked on projects with more sophisticated development processes on Govt. contracts at a University.

    ``The Open source zealots cannot scream the DCMA sucks...''

    Granted `Open source zealots' might be saying that DCMA `sucks' but a far larger number of people, like consumer rights advocates, are saying the same thing. (Though they don't use the word `suck'.)


  • Basically, do you believe (or whatever) in Open Source enough to bet your bank account on it?

    What? If you have a bank account with this bank, you will still be putting your "faith" in the same software. The only difference is now you can look at the source code. I don't see how this tests anyone's faith in Open Source at all. Could you elaborate?
  • Any other insiders with the magic keys?

  • Do you know what code your bank uses? I've no idea what mine uses. It never even entered my mind to use it as one of the criteria for choosing it. Why the should I care?

  • Since guest/guest doesn't seem to work anymore.

  • what I am saying is that this tests your faith in the principles of Open source.

    IBM, for example has the whole series of commercials about the value of IBM services and security.

    The average joe gets easily paranoid about his money, and even imagined threats to it. The average Joe is very vulnerable to FUD.

    Granted that an investment bank is not your local savings and loan. And this is just a developer toolkit.

    but I look at the fud that goes on in other markets, and wonder if this could be exploited in this market.

    and thus the question.

  • Yes I do, however I won't get specific on /. . However I will say that most revenue systems are mainframe based, Unisys, IBM etc. Slow, but batch is the bankers way, old school. It worked just fine for us 30 years ago, why change it.
  • For the same reasons it's considered bad practice to use crypto that hasn't been publicly scrutinized: Security through obscurity doesn't work. If your software is insecure, someone will find it.

    The question is: Will it be found by someone willing to tell you about it, or someone who wants to exploit it.

    If you don't allow the public to scrutinize your system, the likelyhood is that the only people looking at it will be your overworked little development team, and a horde of crackers that don't care that they aren't allowed to "test" your system.

    Whether it's safe or not to use open source software for critical stuff depends a lot more on how you do it.

    First of all, you shouldn't release a banking system and run on the same version of the code until you've let a lot of people look at it.

    Second, firewalls are good. Knowledgable sys.admins that actually keep an eye both on the system, and the buzz in the hacker community, a huge plus.

    Conclusion? If your security is crappy anyway, you certainly run added risks with open source, but if you manage your security well (actually bother to protect the perimiter to your system, and don't run untested software for critical tasks), you'll gain from having good guys looking at your code too, not just bad guys hammering on your system until they accidentally find something (and they will).

  • I guess one must also wonder whether by guessing the password you've illegally accessed their web site. On the other hand, the password was so trivially easy they probably have no leg to stand on.
  • Web servers are not revenue stream. Banks like Perl? No, entry level developers who work in bank development shops like perl. The management of most financial institutions don't even know what perl is. They could care less. They only know that "their IT advisors" (IT guy on board) says Open Source is bad because we don't own it, and bad guy hackers may have put in "back doors" As lame as this seems, I can see 348's point and I agree on the whole "revenue Stream" thing. I don't think he/she was referring to productivity applications.
  • This may come in handy when they decide to Deregulate Banking [].
  • by Frank Hecker ( 1123 ) on Tuesday January 30, 2001 @07:20AM (#470712) Homepage

    To clarify what the openadaptor software is and is not: As the original poster noted, the openadaptor software provides easy ways to set up connections between different types of applications; it is basically an integration toolkit. However the openadaptor software is not in and of itself a banking application. Thus, for example, openadaptor was used to help implement a global equities derivative trading system at Dresdner Kleinwort Wasserstein, but the openadaptor code itself does not perform the financial calculations involved in derivatives trading.

    I should also note that the potential usefulness of openadaptor extends well beyond banking and financial services; any company with large complex IT systems might be interested in it, especially companies that have to integrate systems across divisional or corporate boundaries, for example as a result of a merger or acquisition. (This includes Dresdner Kleinwort Wasserstein itself -- it was known as Dresdner Kleinwort Benson until it recently merged with Wasserstein Perella.)

  • To answer your question, yes, I do know what an investment bank is. Assuming you're the same AC who's been asking the same question (w/out answering it), I assume you do not know.

    Among other things (securities, underwriting, etc), an investment bank often has a brokerage department, a trading department, and a research department. All of these generate money and are ideal applications for a web interface.

    You can feel free to tell Salomon Smith Barney [] that there web page doesn't generate any revenue, but I somehow imagine that they feel differently.

  • Have a look at:

    they both contain real derivative pricing code.

    Laurent Guerby <>

  • where Richard Pryor takes all the half cents and buys himself a Porsche. Somebody should make a movie about that!
  • There is no connection between coding their bond pricing engine into kernel space and their rivals being able download that technology from In order for the latter to be possible, the code would have to be uploaded to first, and this is something the originating bank has control over. (I'm making abstraction of security breaches now, because those apply just as well if they use all closed source products to run their stuff on.)

    It is not the case that all changes to a custom Linux kernel must be made public.


  • Good points; I want my money handled by very old, incredibly conservative bankers who distrust anything that hasn't been proven through decades of use, not a bunch of tattooed, earinged, open source zealots who think that software magically gets better the more people who look at the source code. That whole BIND thing of late has just reinforced this.
  • see subject. Maybe they just don't like my IP or something...

    Amber Yuan 2k A.D
  • Using Open source is not what I stated. Using Open Source or Freeware for Revenue Stream Systems is what I said would never happen. The German company that issued the press release is looking at providing "cooperative plumbing interfaces" for revenue stream interaction between banks and financial institutions. I don't see any major banking consortium supporting this infrastructure.
  • Since it dosen't work I must ask this...Did you try guest/guest or are you asumming all websites have that as a password.... Why don't we do like the movies and type "bypass all security" while we are at it.
  • Financial Organisations will do anything they can get away with to make money, if that means free software they will go for it.

  • It is one of the common combinations to try before giving up, along with /, anonymous/, anonymous/coward, and cypherpunks/cypherpunks.

    (the latter has failed to work recently -- does anyone know whether it has been killfiled?)
  • Will a java implementation be ported to the Amiga platform?
  • Financial Organisations will do anything they can get away with to make money

    Not necessarily true. Financial Organizations will do anything they can get away with to make money in the long haul. Stability and strength make bank customers feel warm and fuzzy. Would you trust your finances to a bank that managed them with Open Source code? I wouldn't. And please don't flame, I'm very much a supporter of Open Source and most ideology behind it. I'm merely stating that banks won't because it's perceived as insecure.

  • Sorry, I forgot to mention: If you will be attending the LinuxWorld conference in New York City this week, there will be a Birds of a Feather session for openadaptor on Thursday, February 1, from 6-7:30 pm EST in room 1E11 of the Jacob Javits Convention Center. The openadaptor developers from Dresdner Kleinwort Wasserstein will be on hand to discuss the openadaptor technology in depth and answer any technical questions you might have. This event is open to all, so please feel free to drop by and attend if you're interested in learning more about openadaptor.

  • Excel has nothing to do with banking.

    You are wrong.


  • Open Source does not mean NON-Mainframe. There are versions of BSD and Linux both open source OS's that run on IBM and Sun mainframes. The recent BIND incident is nothing but another reason WHY open source is so successful. If those DNS servers had been running proprietary code we would never had known how vulnerable they were. Only the hackers would know and they share their secrets amongst themselves on IRC and the Undernet way below the radar of everyone else. was using Microsoft IIS as their webserver. You KNOW that isn't open source. As it turns out they failed to patch their systems as can happen on any OS however the way proprietary patches are designed they often create more problems then they solve so not only do proprietary software solutions become vulnerable to regular neglect but to fear of the solutions themselves! When you can't look at the code not only can you not figure out whats wrong, you can't figure out HOW the fix is going to affect you. A good IT techie will always stay on top of the latest exploits and patches. How can one know everything if the source isn't open? Banks aren't safer because they have until now used closed source they are just more SECRETIVE. 90% of all attacks go un-reported. I know for myself that if I knew what kind of system my bank was using I would feel much more comfortable knowing that it is open source software. It allows for agility, security and speed. With companies such as IBM, Sun, HP, Dell, and Compaq rushing to implement open source solutions this acceptance of this way of using software will only grow with time. The costs in the future will simply become too high for NOT using open code. When something happens and the bosses start asking you why did this happen you'll only be able to answer "I don't know why!!" Why don't you know? Because the code was proprietary and you had no clue what was going on underneath. Thats not a position I would want to be in.

  • Can you give us a "for instance"? Admittedly, I'm not a developer, so this is probably a very naive question, but don't the necessary tools already exist to be able to tie into Sybase, Oracle, Tibco/RV, &c. from Java, using XML?


  • Well its not 100% clear what is meant but I presume;

    RV = TIBCO Rendezvous
    JMS = Java Message Service
    IIOP = Internet Inter-ORB Protocol (or var. Internet InterOperability Protocol)
    ETX = Ethernet I presume? Or something else?
    MQ = IBM MQ Series (messaging middleware)
    UDB = DB2 UDB
  • I'm considering working for one (doing IT/distributed applications at Morgan Stanley) and I'd appreciate a heads-up.


  • If I understand correctly, this is sort of a middleware for middlewares, sitting in between the legacy systems you want to integrate and the middleware. Doesn't this add to the overall complexity of the system?

    The only benefit would be that you can replace your middleware system easier, but how often do you do that? An open-source middleware would be better.

    I work as a consultant in banking and finance and I often see these huge webs of interconnected systems with custom programmed interfaces between them. Middlewares help, but they are not the solution to all problems. You still have to interface to the middleware system. Introducing openadaptor would require you to interface to openadaptor, as well as interfacing openadaptor to your middleware (in case your middleware is not of the systems supported directly by openadaptor). How can this make things easier? Or am I missing the point?

    Anyway, more complex systems means more work for me, so I guess this is a good thing after all! :)

  • The excel bugs are of course interesting. Thanks.

    Even if the Excel has nothing to do with banking, the notion that certian practices, software and hardware could be certified for use is worth looking at.

    For example, that Excel can have these bugs and the Pentium chip can have these bugs, should alert us to that these or other bugs can exist in other tools.

    Security works on secret keys. Safety works on open processes and modular construction. Only an open process can prevent bugs being hidden. Only a modular proces allows the replacement of defective parts in a cost effective way.

    A process can be both safe and secure, because while the process of the key is understood, the exact value of it is not. Banks went for many years with bits of paper and keys. The technology of these were understood. The exact form of the key is revealled only to those who have a valid need for a copy of it.

    Heed excel bugs, not as defects in one program, but defects in our trust in software.

  • But that's my point; look how long it took to be discovered, and this is one of the most widespread pieces of software in computing history. As for the banking industry, crackers shouldn't even be able to reverse engineer it; this is all server-side. And even if they did, it's a hell of a lot harder to figure out a hole like that from reverse engineering a binary than looking at the source code. In my opinion, banking systems should be totally proprietary, by which I mean totally specific to that bank.
  • Thanks. But that just makes it worse :)
  • XML has been touted as the end-all-be-all of system integration. How will this fit into the picture?

  • I HATE that term 'forward thinking'. To me, it means nothing. My old job was all about wordy sales pitches what meant squat. In their company mission statement, the word 'solutions' appears five times. FIVE TIMES!

  • (this is an anti-M$ rant, if you don't like it, don't read it)

    It is about time some rigour is introduced in these systems. Banking relies heavily on Excel, and the bugs in Excel are so deep, an article in Journal of Computational Statistics and Data Analysis concluded that

    Persons desiring to conduct statistical analyses of data are advised not to use Excel.

    Now, it turns out Excel doesn't do computer arithmetics [] very well. It's very, very bad, actually...

  • An AC posted it a while ago.
  • Well, as they've cur that off, I might as well post the contents of the front page from my cache (I only visited that and the licence page, posted elsewhere):

    Welcome to

    openadaptor is a 100% Java/XML-based software platform which allows for rapid business system integration with little or no custom programming.

    openadaptor can be loosely classified as EAI (Enterprise Application Integration) software. It is highly extensible and provides many ready-built interface financial components like Oracle, Sybase, TIBCO, as well as data exchange formats such as XML, Fix, Swift, and HTML.

  • well cheers collab seem to be going in the right directions

    banking is one of the BIG boys and getting accepted in that market counts

    hope that linux does as well for them as it
  • I can with good confidence state that there will never be any real Open Source systems relating to the revenue stream of any major banking institution

    Agreed. Let me give you an example. There are web servers that run within kernel space, and are hence very fast. They're open source and available to whoever wants them.

    Now let's say an investment bank codes their bond pricing engine into kernel space (the faster you can price bonds, the better). Are they going to be happy that their rivals on the opposite side of The Street can download this technology from Of course not.

    Face it, bankers are old fashioned and play things in a very old school manor.

    Lots of banks like perl, of course, but not because it's open source, but because it allows them to write very bad code, very quickly that nevertheless gets the job done. But that's how it works in the Front Office, where short development cycles are everything. On the back office, you'll be seeing the big iron, and I can't see that changing.

    P.S. The whole BIND thing won't have made The Street any more trusting of Open Source. Many eyes only make bugs shallow if they're all a) qualified and b) looking, and the Open Source community as a whole has a long way to go on both of those.

  • I do not work in the banking industry myself.. I do work as a software developer for a large corporation.

    I think taking an extremely cautious approach towards any banking system warrants merit. No bank wants to risk exposing themselves to massive lawsuits over inadequate security over a person's account. I feel certain banks do not enjoy risk beyond working the stock market.

    However, bankers do occasionally embrace new technologies. Witness the ATM machines, which didn't exist as readily today as twenty years ago. Also witness the growing trend in online-banking. As a new technology, open source development holds promise, but hasn't matured yet. But this doesn't rule it out as a viable technology.

    Consequently, I think it's too early to say that the banking industry will never embrace open source. I suspect they simply need to wait for it to prove itself further before they may enjoy its benefits.

    I will gently side-step the DMCA issue to point out that many banks provide their own developers towards projects in-house. Consequently, I doubt the DMCA issue needs to be drawn in here; banks would simply have their developers close whatever security issue arose. And, if the banks' developers worked with open source development, they would probably find themselves controlling much of the software... to include project management (possibly).

    Open source offers a greater chance towards better security than the rather scary practices they currently hold. I've recently read about the transaction protocols used by the banking industry; if they truly use a 56-bit key to encrypt a password without using public-key encryption, in a relatively short period of time, cracking such transactions should become trivial. This is not the sort of freedom open source developers want to see in their information, and neither should bankers. I do not happen to have the URL for this information readily in hand, or I would merrily direct you to it.

    While I'm sure some open source project management might be poorly executed, it doesn't mean all projects are poorly managed. I would point towards the linux kernel itself as a relatively good example of project management in the open source model.

    If there truly is 'no confidence communicated that any application developed in the open source model would not be secure...' this would indicate a failing of open source evangelism, and not of the technology. I would challenge 348 to provide credible evidence of a well-known, popularly used open source project relying upon security that proved to be less secure than its close-source counterpart.. and further, upon doing so, I would challenge 348 to note how long it would take for the project to repair said security issues.

    As for open source zealotry, screams of 'information wants to be free' and whatnot, I suspect these statements show a lack of understanding of open source values, and a misunderstanding of our culture. I would refer you to esr's Homesteading The Noosphere (sic?) for a better understanding of this culture. Of course, as with any group of people, you have your bad elements... but these do not necessarily represent the collective view. It would be like suggesting that all Americans were money-grubbing opportunists.

  • =middleware&action=Search
  • by Eivind ( 15695 ) <> on Tuesday January 30, 2001 @06:56AM (#470745) Homepage
    Well, it just so happens that "best practices" in security-related applications include the absolute requirement for openness.

    That's so because given enough eyes, all bugs are shallow. That's why the most trusted cryptographic systems are the ones whose details have been open for decades, and which still have no known weaknesses. not the proprietary encryption that some company has made, claims unbreakable and pushes as a binary-only product.

    There is no conflict between openness and security. Security trough obscurity does not work. But hi, don't take my word for it, go visit some of the more well-respected security-analysts around and see what they think. Have a look at Bruce Schneiers site for starters.

  • You use middleware. This is middleware.

  • Middleware's once of the nicest types of software you can use when you want to automate operations across diseparate networks, platforms and applications.

    For those who don't know, middleware is like STDIN/STDOUT/STDERR. The bits that join the pipe together.

    It's also usually very expensive, I rolled my own for home use ( using suck/rpost and INN but I suspect this openadaptor stuff will be right on the ball.

  • ETX is TIB/Enterprise Transaction Express.
  • by vidarh ( 309115 ) <> on Tuesday January 30, 2001 @06:57AM (#470749) Homepage Journal
    "That whole BIND thing" was discovered because the source is there for anyone to see. Would you rather that only crackers with nothing better to do than disassembling and reverse engineering the code should be the only one that has the time to look for, and find, the security holes?

  • Some moron...

    You are wrong.


  • We developed this stuff after deploying a middleware product entensiveley throughout our organisation. We wanted to accelerate the other dev teams in the bank in hooking up to the middleware. We didn't want every dev team to be tied to the middleware APIs or to have to do all the standard things (data transformation, filtering, exception processing etc..). You can think of it as the plumbing between the apps/databases and the middleware. Typically dev teams do this kind of work in all sorts of bespoke ways and there is lots of reduncancy of effort in development, testing and support. example: dev teams can pull data out of their database, filter it, transform it and publish it onto middleware. All this can be done by configuring standard building blocks and no code.
  • So I guess you don't work at NationsBank [].
  • Thanks a lot for your info -- I really appreciate it. One more question, though -- I'm apply to work in HK -- developing equity trading systems... Anything else you can say that's specific?

    Thanks again --


  • > Web servers are not revenue stream.

    Excuse me? Banks don't make money with online banking?
  • You fuckwit.

    It's in the context of banking applications. DUH.

  • I only posted it in case the password stopped working. Which it did.
  • And to 348, "I'm not tailgating, I'm drafting".

    Ahh, I see we have an old timer here.. Very good eye, LOL. Go Dale!!

  • If I understand correctly, this is sort of a middleware for middlewares, sitting in between the legacy systems you want to integrate and the middleware.
    It does more than your average middleware; standard components allow you to map and transform the data being transported, plus there's the exception handling systems for bad data.
    Doesn't this add to the overall complexity of the system?
    Not necessarily ;-) See below
    The only benefit would be that you can replace your middleware system easier, but how often do you do that? An open-source middleware would be better.
    Coding to the openadaptor API does mean you are not tied to any given middleware. Most large organisations have many more than one middleware system in use. Say you have an application exporting data over a guaranteed delivery middleware package, and you decide you need to publish the same data over a reliable (not guaranteed) middleware system. Normally you would have to write new code, but if you code to the openadaptor API all you need to do is alter a line or two in a configuration file and you are publishing over a different middleware system.
    I work as a consultant in banking and finance and I often see these huge webs of interconnected systems with custom programmed interfaces between them. Middlewares help, but they are not the solution to all problems.You still have to interface to the middleware system.
    True, but with openadaptor, you only have one interface to code to.
    Introducing openadaptor would require you to interface to openadaptor, as well as interfacing openadaptor to your middleware (in case your middleware is not of the systems supported directly by openadaptor). How can this make things easier?
    Well it won't (if we ignore all of the openadaptor features like data transformation, filtering, field mapping etc.) if you have to write your middleware adaptor.
    However, given a strong open source community who see benefits in using openadaptor, there will be a good chance that someone has already written an interface to your middleware of choice, or if not, they are doing. Or you can, and get the credit and warm fuzzy feeling when someone else uses your component.
    Anyway, more complex systems means more work for me, so I guess this is a good thing after all! :)
    Smiley acknowledged, but openadaptor was written to remove the tedium of writing similar interface code over and over again, a job it does very well indeed!
  • Note that is still password-protected as I write this.
    Then use guest/guest.

  • To describe something as "middleware" is much the same as describing something as a "vehicle" - you're not telling me whether it's a car, a van, a bus, a lorry, a boat, ship, plane, &c.

    To quote from RFC2768 []:

    Application environment users and programmers see everything below the API as middleware. Networking gurus see anything above IP as middleware. Those working on applications, tools, and mechanisms between these two extremes see it as somewhere between TCP and the API, with some even further classifying middleware into application-specific upper middleware, generic middle middleware, and resource-specific lower middleware.

    Lots of things (e.g. Domain Name Service, PKI, Tibco/RendezVous, IBM MQSeries) can be described as "middleware", but DNS is nothing like TIB/RV.

    So... Why don't you shut the fuck up, take the nearest heavy object (e.g. your computer monitor), and bludgeon yourself to death with it. That way, the world will be better off and, more importantly, I won't have to read your [] inane [] crap [] on Slashdot anymore.

    And I'm in a good mood today... :-)


  • Sometimes those of us who are connected to the Internet via an IV and a coffeepot forget how alien this world is to a huge number of people in mainstream society. If banks were to start relying on open source, public perception would not see it as we see it here. The Kmart shoppers of America want to feel that their money IS safe behind old fashioned bars and big blue.

    Additionally, many of the "Old Money" folks in this country are also NOT cutting edge with computers, and stil place great value on the "old fashioned" way of doing anything. Including doing business on a handshake with another actual human.

    And to 348, "I'm not tailgating, I'm drafting".

  • We developed this stuff after deploying a middleware product entensiveley throughout our organisation.

    Which middleware product, just out of interest?

    ..think of it as the plumbing between the apps/databases and the middleware. ..there is lots of reduncancy of effort... example: dev teams can pull data out of their database, filter it, transform it and publish it onto middleware. All this can be done by configuring standard building blocks and no code.

    Aaahh right, this is beginning to make a bit more sense. Would I be right in thinking, then, that this thing manifests itself as a coupla jar's that you stick in the CLASSPATH, and some configuration files or DTDs?

    D. for "Don't ever become a developer, Dodger. I'm not sure the planet would survive."

  • If it's written in Java it won't need any porting (provided there's a decent JVM on amiga).
  • I'm currently using a propietary banking package (homenet from abn-amro, I'm dutch in case you wonder). It sucks. During installation it threw a general protection error at me. Some of the buttons in the program have the same result. It is a 16 bit windows program, obviously written in the good old windows 3.1 days. It doesn't integrate with excel (I wish it did because that would allow for some nice analysis of the data). The GUI is a mess and on top of that it managed to fuck up its internal database.

    In short: it's the worst piece of shit I've seen in a long time. Would I prefer an open source version? Yes, provided it was tested properly by somebody else than its developers. I would like to see banks stop developing their shitty propietary packages and start using the same software (propietary or open-source).

    Your argument about propietary software is not valid since we're talking about client software. What they do on the server side is the bank's business. All they have to do is provide some standard, secure way of communication.
  • If you knew that your bank developed its own software, and you knew it had insecurities but were assured that only the developers knew of them, would you keep your money there? Would you keep it there after the lead developer left?

    Which do you think would be harder to discover: an open source program that skimmed pennies, or a closed source one?
  • both TIBCO ETX and TIBCO Rendezvous, but we also use openadaptor to talk to our mainframe that has MQSeries and variety of JMS implemenations we are using or evaluation (weblogic, fiorano, sonicMq) > Would I be right in thinking, then, that this > thing manifests itself as a coupla jar's that > you stick in the CLASSPATH, and some > configuration files or DTDs? absolutely correct, we use java Properties loaded from files. To run an "adaptor" you run the boot strap program with a configuration file.
  • JMS is the Java Message Service []. ETX is a product from TIBCO []; there's also a TIBCO product called Rendezvous, and I presume that's what the original poster meant by "RV". "UDB" is "Universal Database", used in connection with IBM's DB2 [] database product in its various incarnations.
  • Stop it you bastard.
  • It does use XML. Look at the website using guest/guest.
  • Yu h4ve b33n haXor3d, w3 4u1e2 yu4 401k.

    I know, this software doesn't actually run the servers, it just interconnects them. Still, too much knowledge in the hands of those with too little intelligence can be a dangerous thing.

    Still, it's great to see major corporations not only using open source, but opening their internal tools to open source. One more point for the good guys.

"There is no distinctly American criminal class except Congress." -- Mark Twain