> Here's a fine example: Interoperability between VistA/M and other > systems.
There is never any reason to have an interoperability problem other than when a company decides it is in their best interests to obscure something. The most basic principle of Computer Sciences, as proven by the Turing Machine, is that ALL COMPUTER SYSTEMS are equivalent. > M, Cobol, Fortran - these are considered legacy and most > college students know them simply as "mainframes". But they are not mainframes, they are programming languages which have compilers which product bitcode that is understood by a specific CPU. > Microsoft, Sun, IBM, > Oracle (etc) currently provide Web Services Um, no. Web Services is meaningless. They use the httpd protocols to move information, hopefully with security, through the Internet via TCP/IP. Companies do not provide this. IBM uses mostly the Apache Web Server, as does Sun. Oracle, I'm not sure what httpd server they are using. > and the SOA model to > communicate between systems. SOA is just a marketing term for a watered down SGML document model for communication between systems. It's no different than what has been happening since the days before Gophernet, and HTML. This is not any new ground. BTW, XML can be very inefficient although it can be useful. Remember when WAP was all the crazy. Open Office uses xml based word processing documents and Sordopi uses XML for it's vector based graphics. And PS is just an older based system as well which is theoretically the same thing. You do not want your databases, whose main job is for the security and validation of information, to run on some XML system. They'd never be secure or get anything done. The place for this is strictly in middleware, SOAP etc. > > Web Services != Broker RPC. New vendors that have an application to > offer on the VistA desktop have a high cost of entry into that desktop > for many reasons, and number 1 is accessing the M system. > Just build the middleware and put the published standard out. LEt any vendor who wants to build the client side interpreter. There is no reason for anyone to be locked into anything just because your trying to communicate with the database. > I just saw an email that says the new system works with MySQL. That's > utterly stupid. Not because it's MySQL (I have it running right now), > it's because MS SQL Server and Oracle allow parameterized store > procedures. And that locks everything into a proprietary code base, which you CERTAINLY can't give ***any*** guarantee is going to still exist by the end of the decade. And BTW, MYSQL has UDM modules which are exactly what stored procedures are, except more powerful and faster. In fact, I had dinner with Monty and we were talking about this just about 3 months ago because I was writing another application to leverage this. > NOT using stored procs in an enterprise system is utterly > crazy. Prove that please with unbiased research. The thing seems to work just fine for Google. And for what it is worth, nobody has better support than Monty. Monty has reached right into my machines and fixed problems on the spot from across the world. Ruben ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Hardhats-members mailing list Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
