Slashdot Mirror
Developing for Healthcare - .NET vs J2EE?
An anonymous reader asks: "Our small southern shop (an eleven man team) is about to commence development on some medical software geared for physician's offices and hospitals. Since we have never developed in this area before (our primary source of income comes from developing software for regional transportation offices of the government) we are at loss for the reigning technologies. The two technologies we are considering are J2EE and .NET. What are the opinions of the Slashdot crowd? Surely others have developed for the monstrous healthcare industry. Thanks!"
"My senior manager recommended using .NET. His argument is that most desktops he has seen in hospitals already run Windows, the development time will be cut down for this small to mid-size project, rich desktop clients are possible and there will be no application server costs involved. He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.
Half of my coworkers are with him and the other half have suggested using J2EE due to portability--we do not want to cut off any potential sources of income with an already dwindling future. Has GNU/Linux become widespread in the healthcare industry that we should consider developing for it too? What about Mac OS X server?
The last problem we have is winning over the IT staff hearts. They are the ones who ultimately give the go ahead to purchase the software. Java gets a bad rap for being slow, while Microsoft (and by extension) .NET has the shadow of being insecure. How can you possibly win?"
Half of my coworkers are with him and the other half have suggested using J2EE due to portability--we do not want to cut off any potential sources of income with an already dwindling future. Has GNU/Linux become widespread in the healthcare industry that we should consider developing for it too? What about Mac OS X server?
The last problem we have is winning over the IT staff hearts. They are the ones who ultimately give the go ahead to purchase the software. Java gets a bad rap for being slow, while Microsoft (and by extension) .NET has the shadow of being insecure. How can you possibly win?"
How about some good ol' PHP with MySQL ?
wow, congratulations. you're cool.
are here. Read for yourself and draw your own conclusions
Like say Windows. That way they can't so easily outsource the jobs to some foreign country, thereby depriving some network admins of jobs (and thus unable to afford healthcare).
Mono? go-mono.org
ms is a disease of the nervous system.
try php and mysql for a good result.
Because it simply doesn't matter.
Either your client dictates the technology or he doesn't. The "Healthcare Industry" is a vast array of mixed technologies, so it doesn't matter that way. And if they're buying your solution, they're buying your SOLUTION (which typically involves hardware), so THAT'S not important.
Go with what you know, go with what you're comfortable with. The success or failure of your project will have nothing to do with this decision, just in how you pull it off.
You can find all sorts of excuses to fail in either platform, and you can find just as many reasons to succeed. Pick one, don't second guess yourself, and stick to it.
Good Luck!
Don't ask us. You know the client better than us, and should be able to determine what the best tool for the job is based on the application you are writing, as well as the environment which you are installing it in. Don't make the decision based on what everyone else is using, base it on what will work the best.
Feed the need: Digitaladdiction.net
Both J2EE and .Net pretty much require you to run on a dedicated server, which carries a significant monthly cost. You may have diffuculty getting a private practicioner (with no IT staff) to commit to this. While with PHP, you can easily talk them into a shared hosting plan, and a DSL account for the office to manage things quickly (the two combined will probably run under $100 per month, and you can even make some money on referring the doctor to a webhost)
Ñ'
Your project, assuming there really is one, is doomed already.
You're asking an Internet message board for advice on a development platform? For software you're going to develop for an industry you have no experience with?
http://www.ramp.com
Why write your own when it's cheaper to use an established product?
Ramp corp's software is more feature packed then your 11 person team could do in a couple years of work, it's supported, and you don't need to write code in either of those two crappy standards you suggested.
Unless you have a large body of code already written, scripting languages are a much better alternative. Your development effort will be much simpler, will proceed a lot faster, and should also cost less in software licenses, etc.
.NET applications should then have little trouble communicating with your system.
My favorite scripting language is Python, which has a very clean syntax -- no problem for any Java or C# programmer to utilize fully in under a week. There are other choices, however, such as Perl and Ruby.
If you need to create third party interfaces, use an open standard such as Web Services. J2EE and
Do you really think you'll get a fair analysis from this crowd?
I've used J2EE for healthcare but in general i believe that in a critical system, you may want to use the platform you are better familiar with and do it right ;-)
it's a prime example of how the healthcare industry needs better software!
G(
I've developed in both languages for years and the assumption that most medical facilities run Windows is correct (dentists too).
I think that saying one is better than the other is a sure sign of someone who doesn't know the other language and I feel that you can make as good a product in either language, depending on which language you know better.
How about RMI?
My company runs J2EE but RMI would have been just fine and much easier in a lot of ways. The customer wanted J2EE, of course. Your's doesn't seem to mind.
Since you don't have a preference through your history, I'd recommend using Java. I always found looking for support about Microsoft software to be a nightmare. On the other hand, with Java there's lots of brilliant advice to be found.
Stephan
http://stephan.sugarmotor.org
you want to develop for a new vertical industry that you're not familiar with, you're not sure about your dev platform and you came to /. seeking objective analysis on a platform involving MS?? Well, you certainly deserve all the "PHP rocks!" and "11 lines of Perl are all u need" answers you'll be getting...
Sounds like IT should be making the recommendation based on what their staff will be most effect with.
Any program written for the medical industry that involves capturing patient data is required to be secure. Read up on HIPPA (http://cms.gov/regulations/hipaa/cms0003-5/0049f- econ-ofr-2-12-03.pdf) before making a decision. The company I work for creates software for the medical industry and we chose J2EE for the security and relatively low barrier to entry using open source application servers and tools.
I haven't done much with .NET but I can tell you that J2EE will have a longer life than .NET - the last thing you need is Microsoft changing their APIs yet again to some god-forsaken, bloated, filth. I don't imagine that every healthcare installation uses Microsoft platforms everywhere, either. You're likely to encounter free-thinking IT managers with Linux in various, critical, places where .NET won't cut the mustard. And don't any of you retort with Mono, either. Mono is a curse on FOSS and should be treated with the contempt it deserves!
Every time I compare .NET technologies to Java technologies, I find Java superior in many subtle ways.
I apologize for not being able to be more specific, but I suspect you'll be a lot happier with J2EE.
If the application is to be 100% client code forever, both will work and you should go with what the staff is most familiar. If your staff is equally familiar / ignorant go with J2EE to gain portability.
If you ever want to put some of the code on servers and scale up the system to large numbers of users then J2EE is the best / only choice.
While the application might be portable to Mono if you're writing in .NET, the problem with .NET is, (IMO), that is still a young technology. java is been there for quite some time now, is stable, there is more documentation for it, it is basically a proven technology. Health care is known for not embracing new and unproven technology. And this is understandable, you can't afford a system problem when there are people lifes at stake. If you want them to buy from you, give them something rock solid, something build on a proven technology.
The servers might be Sun's or IBM's, the workstation might run Windows, you ccan create web based or desktop application, you basically have choices. Just to make them feel on a secure ground.
Sounds like you're asking the wrong question. What sorts of applications are you expecting to develop? Is it primarily database stuff? Are you developing for a small or large organization? (given that you have an IT staff, I'd expect large).
The only thing I can tell you for sure is that it's much easier to prove to an IT staff that something's not slow than that something's not insecure -- just show them Eclipse or anything else that...doesn't use Swing...which is the one really slow part of Java.
Really, though, these technologies are so similar that you should probably just pick one and go with it.
-Amalcon
Borland Enterprise Studio is every bit as powerful as .NET and J2EE, and can produce robust fully-compiled code that is easy to maintain and so on.
.NET....and I found that Borland's solutions tend to be more stable, predictable, and reliable. :)
No, I don't work for Borland. I have used their products as well as J2EE and
I really think you should guys should create a .NET solution. The development time will be speedy! Who are you guys? I would love to join your team and tell you what i know about the industry.
Mooch.
Use Java--it's platform independent. In the future, if your clients want to use OS X or any other OS, Java lets them grow.
I've used both J2EE and .NET for commercial systems and would recommend .NET simply because your development time is drastically reduced.
Of course, if licensing budget is a strong concern then the PHP route would probably be your best option.
At risk of degenerating this to another .Net vs Java vs the-rest-of-the-world thread.... (too late?)
I would say java simply because of the number of proven, documented libraries and frameworks with active communities providing good support.
You can argue which platform is the best until you're blue in the face, but I think the most of your time is going to be saved by well documented, well supported libraries -- not language features or server features.
$0.02
That 'java is slow' is a bum rap--maybe it was valid in 1997, but it's not anymore. Also, look into Java Web Start for the ultimate ease in deployment and automatic upgrading.
.NET and J2EE are about the same. Espically when you compare the latest versions, its obvious Sun and MS are in a feature battle. The other thing to look at is licensing issues with using the inner workings of .NET and J2EE. Further more look at performance benchmarks. Java has a bad record with its garbage collector and memory usage (although I hear in newer versions its getting better). You boss is very wrong in saying Java is web-targeted, its everything-targeted to be honest. Also your boss makes the assumption that your clients will want to continue running Windows in the future. Using .NET could imply a OS lockin for your clients (assume mono dosn't fix that for them).
If security is important to you, you do not really have a choice... Windows systems are easily compromised, with MAJOR security problems coming up almost weekly. So you'll have to go with Linux/Unix and that pretty much means J2EE.
We've done a lot of systems with J2EE (mostly financial) and it's been a very positive experience. J2EE has excellent support, both OSS and commercial, lots of excellent tools (many of them are free, take a look at NetBeans or Eclipse), and a proven success record.
Without knowing your specific requirements, I'd recommend J2EE simply because it offers low start-up cost and we had a lot of success with it. Good luck.
A webapp has the strength that all you need is a web browser to view the content. When you update the webapp, all clients are updated instantly, without having to push something out to them, or making them download something. This saves a lot of stress and headache.
There are many technologies out there for writing a database oriented project like this a lot easier. These include
Apache Tomcat, JBoss, and many of the other java based application servers are supported on many different platforms. You can run it on Windows, Linux, Mac OSX, and virtually any hardware provider you want.
I've been working now on this project for 6 months, and I have to say, I love the structure of this way of working on webapps far more than the common hodge-podge of php or perl. This isn't to say you can't program a nice, easy to maintain app in these languages, just that there is a nice framework with examples and plenty of books to do it in Java.
Don't count your messages before they ACK.
This is /.
Anything related to MS is not well-recieved.
Try asking the same question somewhere else.
PLEASE DON'T MOD ME NEGATIVE.
discover Charamel, the best firefox theme around. http://members.shaw.ca/lucx/
And the answer to your question is J2EE. Simply because you can run tomcat, struts and jstl alongwith a local copy of mysql on any old machine. If plans called for scaling (like heavy weight centralized database using oracle) you can do that, if plans call for scaling the app and port to heavy weight app servers you can do that. With MS, your entry point is your max scalable point and there is no scalability.
.NET is easier than J2EE/Struts/Swing at the moment. However this is rapidly changing with new toolkits from IBM and BEA (for websphere and weblogic).
I WILL grant you that developing UI under
Have fun,
Another one of them H1Bs taking american jobs.
Faraz
We've been using XUL for stuff like this for a while
= desktop like interface,
= lightweight desktop install (eg. firefox)
= backend choice of components - eg. prototype in PHP, then decide if you really need to go that extra mile with C for any of the slow bits.
= Users think it's great
= It's responsive, even on old win98 pentium II's
= Alot cheaper to add/change develop. etc.
For the past four years, I have been working for a company that develops healthcare software. We chose .NET for our applications, but I have also done a fair amount of development in J2EE environments. In my opinion, both J2EE and .NET are fine platforms and either one will work. It will be the user interface and features of your application that will ultimately determine its acceptance. People who use healthcare applications are not computer people and don't want to be. They just want to enter their billing, schedule their appointments, retrieve their lab results, etc. If your application allows users to do that quickly and easily, nobody will care what the platform is.
.NET.
Now, having said all that, I will fall back on the usual logic and say that if your application needs to be platform independent, J2EE is the obvious choice. If you want the easiest and most productive development environment, stick with
First off, there has to be a server somewhere ( database ), for a doctors office, a reasonable $2K PC will do. J2EE is web centric, but I have left behind EJB and done everything lately with Tomcat/Spring/Hibernate/JSP/Struts in Eclipse with MyEclipseIde, so much easier. Fat client, you have Swing vs .NET more or less. Last I checked, .NET did not work on Windows 98???, is every hospital running XP??? Java will still work there. And don't think your getting some "Free Ride" on Windows, they will still have to download/install the .NET 1.1 runtime, which, size wise, is close to the JRE. .NET on the client is nicer, but it's still a VM, and not orders of magnitude faster than Java. Assuming there is no need for a large, mission critical, fault tolerant architecture, I'm sticking with the light Java concepts. Fat client, I'm undecided, except I KNOW I would architect it to be driven by meta-data, and not hard coded screens.
Use .NET Webservces. Somone here voiced that PHP/MySQL and a "shared hosting" deal would be better than having a "dedicated server" - they obviously don't know much about .NET. All you really need is a Windows server, somewhere, to run your webservice. Webservices are relitivly easy to setup on a Windows machine. A webservices is basically some ASP .NET and a whole bunch of DLL's. And if you wanted to extend this application so it is a "desktop application", all you need todo is write your frontend and tap a SOAP service.
.NET has a couple nice things, but overall, I absolutely despise it - and that's coming from a long time developper on windows only. I still prefer ASP over ASP.NET (that's sad, isn't it?). Next logical step for me isn't anymore "upgrading" to .NET - it's doing the switch for good. I've had it with them. Out with Win/IIS/SQL server - Moving to Apache (PHP, J2EE, ...) on a *nix box for good in the near future.
And J2EE is a lot more portable (can be hosted on whatever you want, lower costs and maint than a windows box imho)
I used to be a hardcode MS fan, but I guess I'm starting to see the light at the end of the tunnel...
///<sig
Funny that you ask an audience that hates both .NET and anything that Sun does. You should develop it in ogg vorbis. Then slashdot will love you.
Depending on the need for rock-solid reliability, have you considered using a high-level RAD tool?
.NET clone that works cross-platform. If you don't need the power of Java or C#, REALbasic could be a good choice--and you'd never need to port code from platform to platform.
I've had positive experiences with REALbasic, a high-level BASIC-based language that is similar to Visual Basic but compiles for Windows, Mac OS X, Mac Classic, and Linux (GTK). It even makes console apps.
Just tell the decisionmakers it's a
Do yourselves a favor and unplug yourselves from the net. Have a good weekend!
I'd recommend Laszko as part of that solution. It runs on a java server, and I heard rumour that it was being ported to .NET.
Last summer we developed a case management system from scratch for hospital admissions pre-qualifications and tracking. Our client serves the medical insurance industry, therefore HIPPA was a factor. We used LAMP all the way, finished the project in three weeks (no brag, just focus and swinging elbows), and they have fifteen nurses banging away 24/7, client access via https, and 100% uptime. All of their money went to us instead of software licensing, they paid less anyhow, and they are smiling ear to ear.
If the PHP is not elegant enough, for the love of sanity please use Java. If we don't feed the monster that is choking, screwing, and robbing us, it may weaken and we can get on with an unshackled future. We do the entire world a favor whenever we choose sane engineering.
"If no one tilts at windmills, the damn things will take over the world!"- Christian Simpleman
"If no one tilts at windmills, the damn things will take over the world!"- christian simpleman
I think the question applies to any software not just medical. .net framework.
.net most people mean buying into an expensive set of software from MS including a DB and development enviroment.
.net you are trapped. (Mono folks add your comments)
I have used both. I lean towards Java. I like the cross platform option and even though all the PC your boss sees has Windows they probably do not have the needed
You are also not asking a balanced question. When you say Java most peple mean getting the SDK and working with it. When you say
When choosing Java you need to look at the DEV tools. Getting a good enviroment makes all the differences in the world. Jbuidler, Intelli-J net beans are all worth looking at. (I like JBuilder for general use and GUI work).
Also, what is the hosp have on the backend?
If you go Java you have more posibilities. If you go
Try looking throught the archives at http://linuxmednews.com/
There are a bunch of projects relating to practice software, HIPAA and medcial billing.
I work for a small company that does almost exactly what you're talking about, but so far only for hospitals. We have been in business for twenty years now and are having some of the same discussions. We currently run on win32, SCO Unix and AIX. In the past we have supported DOS, HP-UX, Solaris, Linux, AIX, UNIX and WIN32. Most of our customers are running our software (which is character mode btw) on Windows, but our largest, highest paying, and most stable customers are on AIX. If you want large customers you may want to consider something portable. They will usually have a RS6000 running Oracle in the hospital and have many Windows machines connected to it. You can get away with ignoring the RS6000, but that's the most stable machine in the building and IS would love to put it to use. From a support point of view, our customers on AIX and UNIX have the fewest problems and call us the least. There is nothing like trying to diagnose a label printing problem on a Windows network while working remotely over a modem or vpn connection.
Our debate is focused on whether we should support only one OS, probably Windows, or continue to support three. We'll be switching from UNIX to BSD at some point. (Personally I'd rather use Linux, but as a company we are familiar with UNIX and I'm told BSD is very similar.) The Unix variant side likes the security and reliability, the Windows side likes the graphical interface and the fact that Windows machines are everywhere. Plus we have both Windows and AIX customers that insist on their OS of choice. One thing that scares me about Windows is HIPAA, which makes the hospital liable if a patient's information is leaked. No court cases have been brought yet, but the thought of all that patient information on a Windows machine that could get hijacked is scary. A lot of these hospitals allow remote vpn connections and some of these networks get infected with a worm now and then. I wonder how long before someone decides to steal a patient database and bribe the hospital?
Most hospital systems, and even some Physician software will communicate with other systems using HL7 protocol over TCP/IP. This is the thing keeping us busiest now and a lot of times it's what the hospitals find most useful.
Just my two cents, but get used to having the customer tell you what they want and be prepared to do it, if at all possible. Flexibility is key, even more than taking advantage of the latest software trends. Support wise, they will need hand-holding, but they will be loyal customers if you respond to their problems quickly and kindly.
He must work for ramp, because nobody else would claim that shit is worth using.
Bah. The answer is, you shouldn't be using either one of them. Neither you nor your company has healthcare knowledge. If this is a contract, how did you get it? If it's an investor, this is a great way to waste their money.
If you _had_ any of the required knowledge, you probably wouldn't be asking this question. As it stands, you only provided enough detail to start a useless flame war between the two - though so far you've gotten better than you deserve.
So, if you manage to take either ".NET" or "J2EE" and throw one of them in a hat, mix in your clueless developers, and actually _sell_ something, please let us all know, would you?
But I ain't bettin' on it.
PHP is a toy for amateur web developers who do not care about security or scalability, not a tool for serious work.
For a moment there I thought you were considering Java/.NET for life-support machines
( HeartMonitor.java):2319
"Warning: patient's heart rate is -4.12746e28 bpm, which is NaN% higher than the maximum tolerance ofNullPointerException at hospital.lifesupport.HeartMonitor.getMaxHeartRate
http://story.news.yahoo.com/news?tmpl=story&ncid=1 817&e=1&u=/infoworld/20041223/tc_infoworld/52117&s id=96742458
I have worked in a hospital IT department for 10+ years and we support approximately 1000 workstations. Here are a few suggestions:
1. Make it easy to deploy/update. Preferably web based, or your app can update itself. If not, make sure it can be installed silently via MS SMS, group policies, etc.
2. If using a database, you better make sure it enforces integrity and does not try to guess what you mean and do it's own thing. MySQL for example will "help" you by truncating strings and accepting crappy data. You don't want to be screwing with patient data. Lawsuits are common and your data will need to stand up in court. Yes, your app should be able to stop this - but you never know! If open source is your thing, try Firebird.
3. Hospitals shutdown for evenings, weekends, holidays. There is never a "good" time to have downtime. Minimize the need for it and try to build redundancy in your app.
First of all, with Mono don't believe the portability hype. You can port .NET applications over to other environments fairly easily.
.NET is the logical choice because of performance, scalability, and frankly, Microsoft's RAD Tools (visual studio, etc) are far superior to most things you find in the Java/OSS world.
.NET and Windows Server technologies to be easier to maintain and faster to develop with.
There really isn't enough information in the post to make an intelligent decision. Are most of your clients running microsoft software? If so
In addition, with HIPPA requirements and the medical field's demand for accountability from vendors you're going to make a solid case for your platform if it's backed by an entity like Microsoft rather than the mysterious OSS Community.
In addition, J2EE / OSS software generally require a more knowledgable (read expensive) IT staff in place to manage patches etc. The more niche your market is (not so bad for J2EE, but php, python, etc are definately niche) the more expensive consulting talent will become! Microsoft is banking on
In the end though, you need to research what the target markets are using now and tailor a technology that is appropriate for the market.
Hint: There are fairly few recent PCs in many hospitals. So unless you are targeting only wealthy private hospitals, assume the worst.
I use to work on a Unix based custom information system that over a decade old, and on a dozen Unix platforms, and they were developing a new Windows based system. It took multiple years to develop with the new product that was not good enough to replace their existing Unix solution, so hadn't sold a single copy of the new system.
Of course, to your secondary question, I don't know, but I think it is a classic case of horse before the cart though.
No one has mentioned MUMPS yet?
rewriting history since 2109
"What kind of medical facility is this, and how can I check in?"
Step on your tongue.
Java is not that slow. In ye olde days it had a pretty high memory overhead--it still does--but who cares anymore? Memory is cheap and expansive, and (rightly so) people would rather have security and dependability.
.NET simply because of maturity and to stay away from a dangerous MS. We all know that MS has the balls and the market share to squash an enemy by any means necessary, even if that means doing something nasty with .NET. Sun doesn't even has this option. I'm not sure if they have the balls, but they sure don't have the market share. It is in their interest to make Java a viable competitor, not a tool for entrenchment. Their biggest conflict of interest is probably in offering Java for Linux which competes with Solaris. Obviously they are not in a position to withhold support.
I would choose Java over
While I don't have extensive experience with it, you could compile your Java into native binaries...see GCJ and JET.
That having been said, I would definitely consider some of the options presented that do not fall in the binary choice you have presented us.
Finally, while I have not done so personally, my cousin's husband works for a company that develops their product in Java, but apparently can, with not too much trouble, use some automated tools to generate C# for the occasional dead-set MS customer than they come upon now and then. I don't know if tools to perform the inverse exist. He made C# translation sound like fairly trivial an issue for them.
Java is pretty decent speed-wise, but J2EE app servers are often very slow, it pays to be picky about which one you use. Jboss for instance, helps perpetuate the java is slow myth with their terrible performance.
Apache/Tomcat/JBoss has no appserver costs. Oh you actually want support for JBoss? Well MS support doesn't come free either. What will the software process? Leaning more towards patient care (hospital bed allocation, tracking nurses rounds, prescription maintenance, appointment making, etc.) or health insurance management (claims, billing, enrollment, referrals, etc.)?
"Love heals scars love left." -- Henry Rollins
simple choice really, this will give you the ability to deliver a rich user interface along with portability. .net with windows.forms is just going to tie you into a microsoft only.
:)
Also you have eclipse as a development and learning tool
Seriously, C# and Java are so similar, its rediculous to try to pretend development is faster in one than the other.
two excellent options, IMHO the best things currently out there.
. ruby-doc.orgc .trolltech.com
there are both mature and supports standard technology
if you plan something web, have a look at http://www.rubyonrails.org
you definitely needs to give us way more details to receive a definitive opinion.
other references:
http://www.ruby-lang.org
http://www
http://www.trolltech.com
http://do
the worlds best procedure documentation and coding compliance software is converting to .NET.
www.provationmedical.com
-- Scientist: You aren't going to leave me here, are you? Boagh! Thump...
BlueDragon produces a CFML-for-Java product, and ported it to Visual J# (.NET) very quickly. This URL has more information: http://www.microsoft.com/resources/casestudies/cas estudy.asp?casestudyid=15864
toe-programming fetishes aside, .NET does provide better support for RAD, so if you're a practical team that needs to get the job done decently & quickly, go for .NET.
.NET provides better tools to access / export a variety of data formats transparently.
for example web services,
Correct me if I am wrong, but J2EE can't even do client/server scenarios.
.NET you can have clients communicate over sockets to windows services.
.NET for this alone--J2EE can't meet your needs assuming you are doing client/server system. Any healthcare system needs rich clients (that interact with hardware which I'm guessing yours may do). You can roll desktop apps with Java but its painfully slow, and even then you can't communicate with a J2EE system over sockets or have the J2EE server push updates to the client--its still must be pulled by the client.
With
J2EE is purely "pulled" (client triggered). Whether its a JSP, Servlet or Web Service. Nothing is persistently running in background.
I'd recommend
Microsoft is in EVERY hospital around here in the south. I know from New Orleans to Mobile anyway. And kind of suprising to me is that we have over a dozen large casino resorts here on the Mississippi Gulf Coast, and EVERY one of them is Windows and AS/400 based. With windows on every desktop, and usually windows running terminal emulator to communicate with the 400. My company writes software for Hospitals and Casinos and the programmers we just hired are doing everything in .NET
But from talking to these IT managers, alot of them are older guys, and dont know much about linux, and dont care. I have talked to virtually all of them about linux based solutions and none of them were interested. I was really surprised. That being said, these are just hospitals and Casinos in my area, and not nation wide. I would like to think thats not common everywhere. It was like pulling teeth to convince my company to let me build them a linux web server to handle our email and website and keep it in house. Literally took me a couple of years of talking to finally get it done.
Both .NET and J2EE are good platforms for developing and hosting business applications. Both support n-tier architectures via client- and server-side component models for assembling enterprise applications. This allows for use of either fat or thin user interfaces with both platforms. However, .NET and J2EE are far from identical, and each platform has distinct strengths.
The primary strength of .NET is its use of multiple programming languages running on a single platform. This eliminates the programming language as a barrier for adoption. Further .NET strengths include ease of use and speed of development as programmers might be transitioning from COBOL or C. (In contrast, transitioning to Java usually takes greater skill in object orientation.)
J2EE takes .NET's multiple programming-language/ single-platform paradigm and turns it around: The primary strength of J2EE is its use of a single programming language capable of running on multiple platforms. This eliminates the platform as a barrier for adoption. Further J2EE strengths include vendor neutrality and the active involvement of a large, open-source community.
Legacy applications: Can either platform make integration easier?
Healthcare providers are moving from traditional reliance on paper-based records and isolated legacy systems. Most now embraced more systematic electronic exchange of patient data, exchanged both within and across organizations such as other providers, diagnostic and laboratory test facilities, managed care organizations, etc. Creating and maintaining patient records requires the ability to extract and integrate patient data from a range of "legacy" document and system formats. legacy applications constitute an even more difficult integration category. Consider a host application that was developed in-house 20 years ago, and written in COBOL. No J2CA resource adapters are available, nor will they be available, to help integrate these applications in a J2EE environment.
From an integration standpoint, JDBC is actually more promising than J2CA. This API provides access to virtually any data source, from relational databases to spreadsheets and flat files. With a JDBC driver, all corporate data can be connected, even in a heterogeneous environment. In addition to its support for actual relational databases, JDBC can also support emulated relational models based on legacy information sources. But to do this, JDBC requires an integration product that can map the legacy-application functions to emulate a relational database model.
The .NET platform, with its dependence on Microsoft BizTalk Server, has the same drawbacks for legacy-application integration as it does for packaged-application integration. So, despite the very real integration potential of .NET and J2EE, both platforms have their associated limitations. And when it comes to legacy-application integration, neither platform can complete the job on its own.
Be aware that all vendors of application integration products do not provide equal support for .NET and J2EE. Many vendors have built their solutions exclusively around one platform or the other, heedless of the fact that both .NET and J2EE will still be the strongest presence in the years to come. Buying an integration product too hastily can tie your organization to a development platform they might not have chosen otherwise.
Therefore, you should look to application-integration vendors that are closely aligned with--and can articulate a long-term strategic relationship with--both .NET and J2EE technologies. That means checking to ensure that a solution offers interfaces such as .NET Class Libraries, COM Objects, ASP, ASP.NET, and .NET web services to support your .NET-based development efforts as well as interfaces like JavaBeans, JSP, and Java web services to support your J2EE-based development efforts.
I work for a company that just landed a large install to a large hospital system. Here are some points to consider.
.NET AND Mono deployments (or just pick one).
My experience...
1) Don't worry about the run-time in terms of a desktop requirement. Since you'll have to install your software, you'll have the opportunity to install the VM.
2) Getting security clearance to run on a hospital system will largely be dependent on your application architecture and not on your application framework. Do you depend on certain ports or services, certain databases, file shares, web services, etc.
3) A majority (overwhelming majority) of these systems do run Windows. If you find Linux in the mix, it'll usually be for very specific systems (PAX/DICOM) or back-end work (your mainframes and such). Due to the large number of small vendors in healthcare, a ton of applications are installed to the clinican's desktop. (And may have simple architectures or older frameworks like VB, Delphi, and even Terminal/Telnet). Everything from intergrated hospital wide systems to what a doctor uses on his own box to manage X, Y, and Z. [hint: look-up CCOW]
4) Integration with an EMR is important, and again, most are Windows based. If you want to feed data into "the system", be prepared to work with the system. EMRs are heavy on HL7, light on Web Services and XML.
5) Depending on your architecture, your GUI/interface and your "server" can be running on different systems, platforms, and/or frameworks. Probably not the best route but it is possible.
General knowledge and opinion...
1) Mono (.NET) for non-Windows applications is just as viable as Java for multi-platform use. You could do
2) Hospitals pay huge $$$ for integrated systems. As such, they will purchase hardware dedicated to your implementation. If your worried about running on their existing OSX servers, don't be - sell them a Dell running Windows 2003 or a black box running RH. Your software will be more expensive than the boxes. You could also just include $2-10K in hardware costs as part of the PO.
I highly recommend going to a trade-show or just talking to vendors "as a 100-300 bed hospital". You can see what others do by being a customer.
Not saying you have to do what everyone else does - but it does help to sell something that won't take a lot to get going.
Take a look at the Technology Assisted Practice Application Suite, which is based on Zope/Plone (written in Python), the jSyncManager (a pure Java (J2SE) synchronization protocol stack and toolkit for PalmOS-based handhelds), and some custom applications.
This project is geared towards two areas: online access for medical offices, hospitals, retirements homes, etc., and handheld access using Palm Tungsten C handhelds. It uses open tools and open standards, and is released completely as Open Source. Phase One, currently under development, is implementing handheld management systems, security (both validation and encryption) calendaring, and messaging. Phase Two, starting Spring 2005, will be implementing patient data.
Being open and using languages like Python and Java, the suite runs virtually anywhere. The prototype systems are running Debian, however I often do development and testing against a similar setup on Mac OS X (as I develop all of the handheld synchronization and management routines).
Before you go out there and start writing soething similar from scratch, you might want to see if there are Open Source tools you can build upon and extend for your purposes first.
TAPAS is, BTW, being developed in conjunction with a major university, a major hospital, a group of doctors, and a provincial Ministry of Health here in Canada. You might want to take a look at what we're doing before jumping in and starting from scratch yourselves.
If you'd like more information, please feel free to drop me a line. In particular, if your company hasn't even considered the handheld side of your system, let me know as I have a lot of expertise in this area.
Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.
I worked for a Health care applications provider for about 2 years who had developed all their apps using Java JSP using a MSSQL backend and Websphere/IIS.
I'd reccomend Java on an open source platform.
The shop was happy with Java but their main application was badly limited by their MS system architecture and dependence on Crystal for reports. Essentially, between IIS and Crystal, the perfomance was so poor that it was practically a single user system.
This was largely the fault of the shop being focused on "getting the demo running ASAP" and not paying close enough attention to scalability and the cost of scaling.
They were trapped because due to the licencing cost of the servers, it was too costly to scale up the application and the hospitals would not pay for such an expensive backend.
In the end they had to do a costly rewrite and move to open source.
I've been working on the same type of application for a number of years. Small doctor's offices don't have very complex requirements, so even plain old ASP or PHP will work. In fact, many of their functions could be handled by a generic portal application like Microsoft Sharepoint.
I think the database and OS choice are far more important than whether you use J2EE or ASP.Net. Licensing cost and restrictions are directly going to affect your bottom line when you go to resell the software. Stop thinking from a short-term developer's perspective and start thinking long-term and from the physician's perspective.
Have you looked at how complex Windows licensing is? Not only is it complex, but it is purposely ambigious so that people, being conservative, end up buying more than they need. Besides the drag of complexity, the standard Windows server licenses are limited to a certain number of users. The per-processor licensing costs are astronomical for a small business. Asking a doctor to keep track of how many users are using his application is another thing he/she would rather not be thinking about. Personally, restricting a machine whose hardware naturally can support thousands of users to a fixed number of users with hidden software settings I consider obscenely wasteful.
Unfortunately, the application I've been working on is all in ASP, and so barring an expensive migration, it is locked into Windows. If I were going to build an all new application, I would be foolish not to build it on all open-source and free software. I'm not too familiar with J2EE OS and database options, but the combination of PHP, Apache, Linux, and PostgreSQL seems to be a winner. And during your development if you can contribute back to those communities, you will get a warm fuzzy feeling.
Disclaimer: I'm partly your competitor, so take my advice with a grain of salt.
I work in a very large health care system. J2EE vs .net is not important -- nobody really cares what's on the back end. Most of the large institutions are going to a three-tier set up anyway (.net on the desktop, J2EE server side). ... like this --- let's say your patient is on a CT scanner that breaks down in the middle of the scan -- how do you correctly manage the db/billing side of moving them onto another scanner?
HL7 support matters. Make sure all communications are HL7 and possibly DICOM if you are pushing images around -- that is the key. If you are HL7 compliant then the parts your build have a shot at becoming components used in the big shops. If you are rolling all your own stuff and pretend you will own everything cradle to grave then you'll never get more than a snicker from the shops that handle millions of pt visits per year. The standards are big and unweildy because they address many issues you probably would never dream of
Before you start putting this thing together actually get a FUCKING person who will be using this system, sit down with them and discuss what problems they have had with med software in the past.
I really hate the shit I am forced to use to fill out prescrpitions. We have a drop down list for reasons I am prescribing the drug. That list has about 200 selections and the "other" field at the bottom! If I had more clout around where I work I would make the system only have the top ten reasons for prescribing each type of medication and then an "other" field, not this everything under the fucking sun stuff I use now. I swear we have had more problems after we started using medical computers. All I want is a few features that let me be as flexible as need be, not this "we have everything under the sun so you will never need to enter anything outside the options we chose" Doctors hate that crap. Sit down and talk with someone who will use what you are trying to make, that will make the picture 1000x clearer.
The main applications here are delivered to windows desktops through citrix servers and are written in Java. We are looking toward making our new desktop purchases Linux based due to the reduced cost so continuing in Java will be what our software vendors will likely have to do.
I'm tired of those things like ".NET is as good as Java" .NET is there Java was 4 years ago, but not portable. You just can't compare ADO.NET with JDBC (not I'm not mention Hibernate, JDO... erh... CMP?). :-)
.NET - some dumb simpe web pages with simple db access ;-)
With upcoming NET 2.0 well maybe... My bet is for Swing Webstart/Applet Client and JBoss/Hibenate connected by RMI/IIOP and Any DB you wish (even MS SQL not so bad with JTDS driver
(The only thing I could imagine for
Lazy Coward.
Is this going to be a ginormous database, or a relatively small one (local office keeping track of appointments)?
My line of work is in the financial sector, which has similar (though not as strict) privacy/security regulation as the health industry. We're a Java shop partly for this reason, and I think it would work well for your needs.
As far as the customer preference goes, don't sell the technology: sell the solution. Bundle your app with MySQL/PostgreSQL and JBoss/Tomcat and make it painless to deploy. Make it easy to substitute in the customer's preferences (Oracle/DB2 and Websphere/Weblogic) so you can make the sale to those shops which have already invested in such technology.
When it comes down to it, the IT guys will get outvoted by the business. We know it's true, we live it everyday. Deliver on functionality and provide a solution that doesn't require tons of infrastructure to be in place and you will be in a good position.
As a previous employee at a large university medical center in charge of Neurology and Neurosurgery, I can tentatively reccomend Java as a development language. Most of my machines I supported were Windows based, but a lot of doctors refused to relinquish their Macs. Also, for a lot of the research nurses and secretaries, a number of the systems used for scheduling and patient tracking were run from large Solaris installs that were accessed first from a client machine via terminal services and then from the terminal server via X into the actual system. It was extremely convoluted, but having all the X setup on a central server made administration and support relatively easy. In the research labs, we had everything from Macs running OS 9 and X, as well as Linux and the rogue Irix machine around. I guess it is really up to you on what size hospital you will support, as I imagine a lot of smaller ones are Windows only, but in the University environment, where doctors are training to be out in the field, they were exposed to a wide variety of systems and are capable of handling just about anything you throw at them.
Speaking from expierience, I worked several years as an IT Manager in the healthcare industry in Connecticut, the most important thing I was forced to consider was ease of use and speed. While security is always a concern, it sometimes had to take a backburner to speed and just plain old usability.
.Net as that is what, from my expierience, is going to get you the most market share. Make it run quick, and by all means make it simple to use.
I cannot speak for other healthcare industries in other areas, but we were a 100% Microsoft shop with the exception of our Web Server. Almost every application that I looked at in my time as IT Manager was a windows based application. I have no problem with Linux, and I personally prefer it, but not many crossed my desk. I would say about 95% of the applications I saw were Windows based Apps.
Perhaps the best thing for you to do would be to try and do some research on your target audience (Hospitals, VNA's, Single MD Practicioners, Multiple MD Practicioners, Walk-in Clinics etc.) and if possible find out what type of servers / software / brands they are currently using. You are going to get some people that will not give out that information but some will, and it is all in how you approach it that will get you that information.
In the end I think you are going to find that it would be better to go with the
Brian
Upfront statement: .NET on campus, and am currently not paid for this position. So, in a nutshell, I basically promote the technology because I really like it. However, I think Java's pretty cool too.
.NET - I've seen even some grad students putting together a pretty awesome application in C# .NET for a programming competition that was aimed at the health care industry and had great acceptance with the hospital. The development time is quicker (especially in VS.NET), there are definitely security/cryptographic libraries implemented, and there is a huge open-source community built around .NET programming.
.NET framework has been ported in a large part to *nix with the Mono project and has been used quite successfully in Munich which has recently ported to Linux by a company called Volcker.
.NET and .NET was much faster and much cleaner as well. Plus, you can inherit from old C++ classes and leverage existing code/libraries in your new application.
I'm a Student Ambassador to Microsoft, I've been promoting
My thoughts are that yes, it will definitely work in
Also, the
I've developed GUI applications in both Java and
This sig donated to Pater. Long live
FYI, here is a list of common technologies you will see floating around a typical community hospital:
.NET.
.NET, and that the question is kind of a moot point.
operating systems
digital HP Unix
AIX
VAX/VMS
Solaris
Windows 3.1, 95, 98
Windows NT, 2000, XP
programming languages
Mumps (ala the 'M' database)
CCL (fourth generation SQL-esque language)
SQL (a very little bit)
databases
oracle, oracle, oracle
some SQL
First of all, you have got to understand your (potential) client. Therefore, you need to understand FDA regulation of healthcare equipment, and of the HIPPA regulations. Because of FDA regulations regarding healthcare equipment, it often takes years (between 3 and 5, on average) for a piece of medical equipment to be designed, tested, run through trials, and (hopefully) approved. On the other hand, hospitals have a very steady stream of revenue, charge lots of money, generally have massive amounts of cash flow, and have major assets (like CT and MRI scanners, for instance). Therefore, it's common for a hospital to invest $1M for a new CT or MRI scanner at least every 10 years. However, that scanner had better be a workhorse for the hospital.
So, what this means for you as a developer is that most hospitals still have legacy systems in production that date back 10 to 20 years. As a systems administrator for the department of radiology at a local community hospital, my production environment involves:
> a Maxifile VMS/VMX terminal server running an 'M' database programmed in 'MUMPS'
> 6 oracle database servers which 100+ non-admin end-users log onto each day
> a remote-hosted oracle database which sits in Kansas (ala Cerner Corporation), which everybody at the hospital must access via a Citrix box.
> a nuclear magnetic resonance imaging scanner running VAX/VMS
etc. etc.
So, to make a long story short, if you want to develop products for the healthcare industry, you had better start thinking about how to interface with products from Oracle, Citrix, Cisco, Microsoft, and so forth.
Also, Linux is generally avoided in hospital settings. It requires too much computer knowledge (remember that hospital workers are healthcare providers, not information technology developers). More importantly, it's usually impossible to hold the developers accountable with Linux, and it's generally very difficult to obtain support contracts. All things considered, I have 1 linux machine in production, 200+ windows machines, and about 30 unix variations (AIX, VAX, HP Unix, DEC, Solaris).
So, all this being said, I think that you're barking up the wrong tree and not necessarily asking the right questions. Personally, I would suggest J2EE over
If you really want to start asking the right kind of questions, you could start with questions like 'should we start by developing an HL7 sniffer or a HIPPA auditing & compliancy application'? You would then find, either way, you will need to know Cisco (TCP/IP stacks), Oracle (SQL database connectivity), and HIPPA legal concerns (e.g. need for cryptography). In the end, you'll realize that you can do it in either J2EE or
anyhow, just my $0.02
Okay... so from the MASSIVE listing of replies here, this is old ground. I myself have researched this extensively and have found hundreds of companies that are implementing a solution similar to this or are in the process of doing so. This also inclues a number of open-source solutions to the problem. Unless you can truly bring something interesting and new to the table, (and I assure you that finding new and innovative ideas without a tremendous ammount of work in this industry will be *very* hard), why develop something with such a limited market that's saturated with incumbant service providers?
As far as the debate over a: or b: well, it's truly a function of what you and your guys will have the best speed with and what you can support easiest. Both platforms are robust enough to do the job well. It's just all those other factors that get in the way such as the client's needs and the overall cost of developing on wither platform which I won't comment on here as it has already been laid out in full above.
From having used both, I would say that Java is more mature, but .Net has some easy-to-use APIs and IDE features. Java can have a more difficult learning curve, and can take more time to get it right if you aren't experienced. I would use Java, but if you have more experience with .Net, I would go with that.
Instead of re-inventing the wheel, get involved in open-sourced solutions. You can find a good list here.
From this list, I have personally only seen VistA which has been used by the Veteran's Affairs Department for a very long time. Certainly long enough to mature. It's scalable and will work with groups of hospitals. It's designed by Doctor's to fit the way they work and it's easy to use (so Doctor's have told me). It's open source, and there's a community web site.
There are cons though: It uses a little-known programming language called M, and although otherwise complete, does not have a module for paediatrics (it's very hard to find child veterans!). The people I have met have been extremely helpful, however, and will help you with any customization or new capabilities.
Try this J2EE app -- it does 99% of what you need, just customize it for your locale, and let 'er rip:
p lications/HealthcareApps.asp
http://www.pega.com/ProductsServices/HealthcareAp
J2EE .NET
.NET ..... x86_64 coming? Maybe.
.NET.
.NET?
Windows, Linux, AIX, Solaris, OSX, etc
Windows
J2EE
x86, x86_64, Sparc, PPC, Alpha, IBM-Mainframe (quasi PPC)
x86
So you can develop your software in J2EE, use the free Eclipse IDE, on a free operating system, with a free application server (JBoss). J2EE has years of experience and large scale deployments as well as numerous books of reference and scads of talented, experienced developers. You have a choice of platform unrivaled by
So, wait, why program in
The only thing JAVA is remotely 'slow' at is on the GUI side of things, and that really isn't much of an issue these days (thanks to faster computers, better swing, and SWT).
FunOne
His argument is that most desktops he has seen in hospitals already run Windows
"Most" already implies that his solution won't work in all hospitals, while yours will. Furthermore, the reason he gives isn't a reason at all - it's trying to ward off accusations of lock in.
Even if all the desktops ran Windows, that wouldn't be a reason to use .NET, that would simply be less of an advantage to J2EE. The advantage is still there of course, because there's no lock-in with J2EE.
the development time will be cut down for this small to mid-size project
Where is he getting those numbers from? If all your developers are experienced with .NET and none with J2EE, then it's reasonable. If it's just something he read on microsoft.com, it's not.
rich desktop clients are possible
The same applies to J2EE, so you can throw that point away instantly.
there will be no application server costs involved.
There are Free application servers available that do the job quite nicely.
He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.
He's arguing from a position of ignorance. He's comfortable with .NET and he doesn't know much about J2EE. Unfortunately, the kinds of managers that are willing to argue when they don't know the facts are usually the hardest to educate. Figure out his complaints with J2EE, and then show him that he is wrong (diplomatically) in specific terms, relating to specific products and components.
Cross platform. Easy development. C++.
Nexaweb technologies has a rich client/J2EE solution you may find interesting. http://www.nexaweb.com/
Our small southern shop (an eleven man team) is about to commence development on some medical software geared for physician's offices and hospitals.
.NET or J2EE environment that should have been caught at application design time.
I assume that you're delivering a product, and that you have some previous expertise and previous experience building a somewhat similar product in a different field.
If so, my first answer would be to "do what you're an expert at". Why screw around with technologies that you all aren't expert in?
Is this an "old fashion" attitude?
You bet! You're there to deliver a successful product, not learn about the production issues of a
Evidently your 11 person team is a technical team that has been built to deliver successful products. Use their expertise. Enhanse that expertise. Don't abandon it, and don't think that since you're great at one technology that you'll immediately be able to switch to another environment with any measurable degree of success.
If you're looking for an opportunity to learn new technologies - great! Just make it a minor part of the system, and make sure you have an "escape route" if it doesn't work out the way you hope it will.
PS - My ex-girlfriend's shop (she's an MD) runs both Windows and Unix on the back end. The IT folk treat applications like a black box - they don't care what application server you use - and they won't be messing with it. But I'm not a global expert on Hospital infrastructure and IT practices.
PS - I don't think it matters if you're a southern if you're planning to sell outside your regional medical area. However, if you plan to sell to a particular hospital, then it very well could matter how you build your product.
Just choose the option that you have the most experience in. The marketing hype is just that: hype. I have had the experience in designing solutions in both and basically both are almost the same.
.NET. There are still more open source tools for Java (Hibernate, Ant, etc.) but the .NET versions are not far behind (NHibernate, NAnt).
If you have more developers with experience in Java, then choose it. Same goes for
I still prefer Eclipse to Visual Studio.NET, but really you will get more "bang for the buck" if you don't have to go through a learning curve.
No matter what you use, they will all die a horrible terrible slow and painful death.
Why do they come to me to die? Why do they come?
You can't handle the truth.
on blogs.msdn.com. That way you'll get answers on both sides of the religious wars.
(Go ahead, mod me troll. I'm already married so I don't have to impress anyone anymore.)
Cerner, one of the largest vendors in the clinical marketplace, is porting to Java and Websphere right now. Their java base product should hit in 2006.
.net then they are tied to a M$ OS and M$ tools. By developing in Java they can run on M$, Linux, UNIX, OS/390. Their code will scale and will port when one or more of the platforms is no longer popular or effective.
Think about the reasons they would choose Java. If they go with
So you need to ask yourself. Are you targeting low hanging fruit or planning to grow and have your code grow with you?
Both systems have snags.
.NET is here to stay, who knows what it will cost to continually develop with it (past experience tells me much more than on Linux or a Mac). Plus .NET is somewhat new compared to J2SE/J2EE. And, while Java isn't 100% secure, I'd feel a little nervous building on something with the security record that Windows has. While Java's sandbox isn't perfect, it's prob a safer bet than .NET.
.NET probably isn't the best thing either. With Java at least you have many choices for app servers and even hardware/os environments whether it be Linux, Mac, Solaris, or Windows.
.NET and with SWT, you can even have the look and feel of Windows on Windows instead of the fugly Swing look.
While Windows people might not see it this way, I think being limited to just one platform is not a very long term development solution. While
Also, I don't see single language an issue. C# people will stay there, Java devs will stay with Java. However, Mono being the only compatible solution to
I've gone thru these things in the past and I feel much freer dealing with Java than I ever have with Microsoft. I don't feel Java is necessairly slower than
Real programmers use Perl, LISP, or Python. Paul Graham even said so.
Design for easy HIPAA compliance. Will the system gather, use, or store Protected Health Information? If so, make it operate such that as little of the PHI as possible is even cached on the desktop machine, and that the desktop machine stores none of it.
:-/ You could make platform-independence a major sales feature.
Platform-independece is nice. I am stuck with a vendor who provides windows-centric products. My docs have Apple laptops, and want to use the apps.
Most small to midsize clinics do not have IT staff. Maintaining application and/or terminal servers is probably easier for such a clinic than maintaining many windows desktops. They're used to maintaining an accounting server; your app server is an easy addition.
With reasonable men I will reason; with humane men I will plead; but to tyrants I will give no quarter. -- William Lloyd
Thank you all for your help answering my Java vs .NET dilemna. As a quick follow up, now that I know which development platform we should use, do you recommend Windows, Linux or Mac?....now also I am looking for the best religeon for my family, would you recommend Judiasm, Islam or Christianity? Also me and my team of friends are thinking of voting, should we vote Republican or Democrat?
-Annonymous User (Not a Troll, really)
My senior manager recommended using .NET. His argument is that most desktops he has seen in hospitals already run Windows, the development time will be cut down for this small to mid-size project, rich desktop clients are possible and there will be no application server costs involved. He also contends that .NET has more templates and abilities than J2EE (which is simply 'web targeted' in his opinion.
.net only works on certain version of windows (I'm thinking 98 and above. Not sure about me).
How many desktops has he seen in hospitals? What version of Windows were they running? You know
Coder's Stone: The programming language quick ref for iPad
And that doesn't mean Struts. Spring seems to be popular. I prefer Open for Business (www.ofbiz.org). But don't go reinventing the wheel and don't spend your time writing JSPs.
No offense to the Mono folks, but I just don't see them ever having 100% cross-platform capability. It will never be possible to seamlessly change your development and deployment environments from Microsoft.NET to GNU Linux/Mono. And if it ever does become that easy, Microsoft will be ready with some kind of nastiness (patent lawsuits, forced upgrades, etc).
The group I work in writes custom engineering (design and anlaysis) applications for our company (Fortune 100). Some of these applications have been ported several times over the years as the flavor-of-the-week OSes/platforms changed. And today we're still porting applications to Windows using MFC! What happens when Microsoft obsoletes MFC, or Linux becomes the standard for engineering desktops, or even Apple starts supplying top-of-the-line technical workstations? We'll port again! But now is the time to take advantage of open source, cross-platform development environments.
Spend your time working on a solution for your customer, rather than worrying about future portability issues. I just feel that if you go Microsoft now, you'll regret it in the future; I just don't see how anyone can make a reasonable justification for going with Microsoft and claim to have a solid long-term vision.
Even Microsoft's lame slogan, "Where do you want to go today?" supports their obvious short-term approach. Today just isn't as important as tomorrow: I know where I need to be tomorrow; once I figure out how to get there, what I do today will naturally be right.
I work for a very, very large insurance company with tens of thousands of employees, and several dozen million policy holders. At least 25% of the nation has auto insurance with us.
.NET in the enterprise for a while, until Humpty Dumpty (.NET) fell off the wall and all of Microsoft's Men and Women couldn't put it together again. For two and a half weeks customers were without quotes, or access to their policies online, and agents couldn't sell new policies or make changes to current policies. Customers were furious, agents were foaming at the mouth in anger.
.NET team flown in they couldn't get it working again for two and a half weeks. Eventually they had to rebuild the entire server room with new Windows installations on every server because they couldn't find out the problem. That might seem bad, but let me make note that the whole system was provisioned, installed, and maintained by Microsoft personnel. They broke it and they couldn't fix it for, say it with me, two and a half weeks. That should make it seem worse, but it still sounds better than it actually was.
.NET. We don't even get Visual Studio.NET installed on our development machines anymore. We have a very strong bad taste in our mouth from the whole .NET craze, which Microsoft is going very far out of their way to remove, without result.
We used
Two and a half weeks. With all of "the Shining Stars" of Microsoft's
A decision was promptly made to drop
We use J2EE and are very happy with where its going. Sun has spent a great deal of effort working with us to transition, and their support has been great. Our J2EE stuff Just Works. It works wonderfully. We are very, very happy with it. I'm using short sentences here to get the point across that we are very happy with J2EE. We've been using it for our web services and as our main development platform. We train on IBM's WebSphere Studio Application Developer, and it also is a great (but expensive!) tool.
I, as a developer, recommend J2EE. I do not represent my company in this recommendation, in case you work out who it is I work for. I am speaking totally on behalf of myself.
I work for Compuware, if you are at all concerned about ease of development and cost cutting you should consider using OptimalJ. This is basically a UML to J2EE application builder plus integrations for accessing legacy systems. It supports a wide variety of IDE's, appservers and databases. You can check out more at: http://www.compuware.com/products/optimalj/
I would actually reccomend python instead, you can use all the win32 libraries, and when iron python gets mature you could recompile into .net, but the advantage with python is that you can use dist-utils to spit out a regular win32 binary, so your app can run on lowly windows2000 or even win98 machines, python supports a much larger subset of the older, cruddy machines they may be running at hospitals, but it would scale out for larger systems.
You can use tkinter to create GUI apps that will run on windows, linux, osx, even mac os 9.
http://www.linuxmednews.com/
Medical software is one area where we should all agree that closed source code has no place. After all it is not like a life support system, it IS a life support system. Closed source code for medical applications is like selling drinking water in a life boat. It's wrong.
And while we are on the subject, can anyone explain why we let the government mandate via hippa the use of diagnostic codes that are not in the public domain. Thats right the AMA owns the diagnostic codes that the government mandates. And we all know the AMA needs all that money from licensing.
I've seen plenty of programs developed in Microsoft environments that needed runtimes or extra "stuff". We have Foxpro, Access2, Access97, and VB apps at work that all require this crap. I wouldn't doubt for a second that .Net or any other Microsoft product would need extra stuff.
Do not look into laser with remaining eye.
The company I work for is in the process of porting all of it's VB (.Net predecessor) software over to Java. The reasons are pretty interesting.
.Net, forcing a rewrite that will cost millions. Microsoft is infamous for churning its technology base, so they could easily do it again. Fool us once, we aren't going there again.
.Net (Mono is not even close to be considered - one patent infringement lawsuit from MS and it is gome). Java gives us access to just about any platform we are likely to need to deploy to.
.Net is famous for crappy performance on more than 2 cpus. Java runs great on big iron.
.Net's use cases are not.
- Microsoft essentially obsoleted our entire company's code base when they introduced
- Java has been around for 10 years, with many fewer technology upheavals.
- Java is multiplatform, much more so than
- Scalability.
- App servers - With MS there is one choice. With Java there are many vendors, with a vast range of product capabilities.
- Development tools - Just as good, wider variety and often far less expensive per seat.
- Maturity - best practices are fully understood, while
How the hell does something this clueless get posted as a story???
Before you get started, head on over to LinuxMedNews.org
There are many Open Source EMR projects that could use more help.
Pat Evans
I work for a small home health care company that uses prompt 8.0 through Lewis for an outrageous amount of money. In my personal opinion small home health agencies need a scheduling program targeted towards them and not larger corporations. I know we are interested in something cheaper. Good Luck.
you want to develop for a new vertical industry that you're not familiar with, you're not sure about your dev platform and you came to /. seeking objective analysis on a platform involving MS?? Well, you certainly deserve all the "PHP rocks!" and "11 lines of Perl are all u need" answers you'll be getting...
Very true.
But let's put the blame where it belongs -- on Cliff, for posting the post.
-kgj
-kgj
A few weeks ago I visited a friend a one of the four area hospitals, I now know were I don't want to be sick at. Each room on his floor had some type of monitoring equipment outside the door in the hall and was running standard Win2K Pro. Any OS that can run J2EE can run your app, but if you do it in DotNOT then your are fusked. To the opening statement I prefer a specialized piece of equipment run a specialized OS and software. BTW, I worked in the past with a company that produced a machine that stamped out metal sheets for parts moving 5 feet/second. The end user programers [engineers] often wrote bad that jammed the sheet clamps into the tool turret, requiring a 15 ton puller to remove it from the tool turret. So yes, any OS/app can fail but I do not want any application that is mission critical [including privacy under HIPAA, which I now am involved with} monitoring/controloing anything mission critical or private running anything generic from Microsoft.
I would recommend the developer go with the most mature performant stable tech that he is also experienced with.
I think that you have this idea laready, but i must steress the inpoortance of having a front end that can be accessed form a web browser. As a sidenote, why not use SQL and hardened PHP to do the back end?
411 Y0UR 8453 4R3 8310NG 70 U5!! -NSA
If you are a smallish shop used to some of the older technologies, I suspect you'll be annoyed by the overhead in both C# and Java. I would take a serious look at Python. Python can be run under the JVM, .NET CLR or native-it is also a nice, accessible language for a team of your size.
The infamous MS vs Everyone Else rears it's ugly head, yes? For the sake of Making Money(TM), I suggest you put that behind you (That goes for all of you). As the (lonely, sole) architect of a multi-million doller clinical trials processing system (100M+ records, 20 million+ lives, etc), I can *promise* you that any enterprise system you build will be composed of multiple technologies. You could build it all in MS. You could build it all in J2EE. You could build it all in Perl if you're into self-flagelation. Your best bet is to develop the process flow to mirror the business model, break it into parts, and then let the needs of the application dictate the environment, at least to a certain degree. Need super solid networking between disperate clients? Java. Lot's of different data formats? HCFA? UB92? NFS? Legacy mainframe crap (I'm talking to you, Envoy/WebMD)? J2EE. Need the libraries for all those HIPAA-compliant, OIG compliant FDA compliant 'snapshot of every record in so-and-so format' stuff already written, with a company full of people to yell at when something goes south? MS has it already finished for you.
:)
Developing and architecture is fun. To make $$, however, you may need to put your personal preferences regarding platform, environment, etc aside, and let the needs of the project dictate some of the development decisions. At least more so than usual.
If anyone walking the dark road of HIPAA conformal, HHS nazism type transaction handling wants to discuss off-list, mail me.
wsharrison@gmail.com
Director of Implementation OmniComm
While .NET is here to stay
.Net is going to become 'legacy'.
We thought VB was here to stay, too. I bet Longhorn is going to mean that a lot of what people are doing now in
It's really a question for the client. Who is the app for? How do they like to work? Will they need remote access? If successful would there be a possiblity to integrate other apps into this platform?
Not to mention that asking ".Net (native client) vs J2EE" (since he's already decided for a .Net client rather then a .Net webservice) is like comparing apples and oranges.
I'd like to moderate the question -1, Dumb.
using System.Awesome;
From what I've observed so far in the field, I don't think almost any hospital/medical office environments are running Mac OS X Server right now. (You tend to see it more at the research/lab level.)
There are already a few packages for Mac OS X out there to run small dental, doctors' or chiropractic offices with - but you'll tend to see these running on several networked iMacs, in more of a "peer to peer" environment.
If you *do* have concerns about your new product being compatible on OS X Server, I think you almost need to "go all the way" with that goal - and push your product as a niche-market leader in that area. It may or may not really fly, but being first to market in an area is usually a good thing. (EG. If you build it, they will come.) Maybe some hospitals would consider Mac OS X Server purchases if they knew there really was a high-end vertical market product available, designed specially to run on it and take advantage of its capabilities.
As many have said, your details about your application's future environment are rather vague. I'll attempt to provide some slightly insightful chatter, though.
.NET route. You'll be locking client in, and that's never a good thing. Whenever they wish to migrate, and they can't, no more contracts for you.
Many hosptials usually have assorted UNIX systems, AS/400 databases, and a few Windows servers for the end-users. Anything useful can most likely be found on the UNIX systems or AS/400 databases. Likely, if you're being contracted by a hospital, your application will run on those assorted UNIX systems; however, if your application requires a Windows system, they'll gladly give you one.
Typically, hospitals are pretty big on AIX and Solaris, and AIX and Solaris have *very* nice J2EE environments (especially, Solaris). You'll score a few points with IT blokes that have AIX or Solaris certs if you write in J2EE.
I would *highly* recommend against going the
You've asked about portability, and J2EE is the way to go. Want BSD? Fine. Want various Unices? Fine. Windows? Of course. Linux? There as well.
J2EE isn't just a UNIX/Linux thing. Sun cares about the Windows VM as much as it does it's Solaris VM. Ask Microsoft the same, and post the reponse you get.
There's pissing contests all over. OSS is just another one.
Flamebait? that wazs the first thought in my head too. If I was in charge of hiring someone to program my healthcare system I'd make damn sure that they have enough expertise to choose a freaking language. How can you trust them to deliver solid mission critical apps if they are going to depend on a savage hoarde of wild geeks to tell them how to do it? Sorry dudes, don't take this the wrong way, but as most of us already know, the days when you could learn html and some scripting, set up a job interview and list your demands, then get hired are long gone. People found out that using frontpage isn't that hard. This has nothing to do with those coding gurus who really know their shit, are creative enough to design complex solutions, and dream in fortran. Guys that can bust out inovative, commercial quality apps still posses a valuble, uncommom skill, and none of them need help from slashdot to pick a language. Wish ya the best of luck with it though, I really do hope I'm wrong.
Ruby on Rails is a nice newer platform for doing database development.
I use .NET when I want to develop the application faster. It is a lot easier to make web services on .NET than on Java. The bad part is that you are limiting yourserlf to MS servers. Of course, the database servers and everything else can be run on whatever else you like. The client can be in .NET, JAVA, a browser, it doesn't really matter.
.NET for the app servers.
When I develop for portability I use JAVA. I can run it on any server that I like. Then again, how many times are you going to switch servers?
Because of what I mentiones above I find myself more and more using hybrid systems. Linux for NSF and file storage and
Cheers,
Adolfo
REALbasic does cross-platform far better than Java. It creates native executables and compiles to machine code for the platform you choose. This means you can support Windows 98-XP, Linux and Mac OS X if you like all from one code base.
.NET because it's secure (it compiles to machine code rather than byte code).
It's also better than
Now before everyone chimes in about BASIC, this is a modern, object-oriented BASIC that is as object-oriented as Java. And you won't have any performance problems because again, it complies to machine code.
You can check it out at http://www.realbasic.com.
Rather than say X is always better than Y, here are the relative benefits as I observe them:
.NET if a rich user interface is the most important. Microsoft's client-side extensions are the most feature-rich, partly because they control the desktop standards still.
*
* Java if security is the most important
* PHP if responding to business environment changes is the most important. Dynamic typing generally leads to quicker product turnaround times and higher productivity.
Table-ized A.I.
In the end either language can work. If the app is a client server app, the .Net would probably work reasonably. Any decent programmer is not going to cry over one language or another. They may have preferences, but in then end the job dictates the tools. I personally do more java than .Net, but this sounds more like a .Net job.
I'm a programmer for an insurance company.
.NET and get it over with. I spell it M$ and would love to see java prevail more than .net, but the reality is you'll mostly encounter Windows shops and people who may have simple prejudices against java (viz it's slow, etc.). Even if it's compiled to a windows app and is easy to use & install, catchphrases like "it uses .NET technology" will go far. Even hospitals that use mainframe or unix backends will have their PCs running windows.
Healthcare companies do not have top of the line cutting edge IT technologies; they're years behind the cutting edge, and they're IT departments usually have people who's training and experience reflects this.
More so for doctors' offices & small clinics. They will have no IT and be running something in windows.
Hospitals are the only ones that may be a wildcard, especially university hospitals. Their systems could range across the board. That's my impression...I'm least familiar with hospital IT shops.
My 2 cents: do
If java is the way of the future, then the healthcare industry will catch on years after the fact. Right now they're living in 1998.
I've been with the company for about 3 years, doing both Software development and system support. During that time, most of my development has been in Java. I have yet to see any .NET development.
There may, in fact, be .NET development at Kaiser, but I haven't been able to find many references on the corporate intranet.
I would summarize Kaiser's software development as follows:
In the last few years, Kaiser has had an apiphany regarding in-house software development and now leans towards vended systems. But there is still a significant amount of in-house software development done to integrate these vended systems.
Hope that's useful.
-S
I would say J2ee due to portability, but I think for your purposes, J2ee is going to be too structured. Stay with me here for a sec.
.Net in various flavors has an easier time because it allows for a looser design.
You don't know much about the vertical and your dev team's split. You're going to have a lot of design changes. In my experience, J2ee has a lot of problems handling design and code structure changes, while
But yeah, keep your resume dusted unless the company you're working for has deeeep pockets.
--
Vote for your hopes, not for your fears - Vote Third Party
OK, first my background. I used to work in behavioral health. I changed industries about two years ago. I've worked extensively with both C# and Java in the last four years. My thoughts:
.NET client application than a Java one. Note that I said behavioral health, which is a smaller niche than healthcare in general. I don't know much about the larger industry.
.NET. Either architecture can be made to scale, but Java provides sane architecture for things like transactions (JTA) where .NET makes you roll your own. I really think .NET glossed over some enterprise features to make things easier for the novice where Java forced you to think about doing things right.
- Almost everything in behavioral health was on the MS platform. If you're writing a webapp, this doesn't matter, but you'll have a slightly easier time selling a
- If I want to turn out something quick and dirty, I can do it faster in C#. This is because the Visual Studio IDE is desgigned to make building user interfaces easy. It's not perfect, but it's great for prototyping and I can fine-tune the generated code. I have yet to see a UI-building tool in Java that can rival this. (This line's gonna get flamed because I haven't looked very hard.)
- Eclipse (for Java) is by far the most powerful and useful IDE I've ever worked with for coding. It blows Visual Studio out of the water for writing code, but it doesn't have UI building tools. Use it and you'll learn to love the refactoring tools and junit integration.
- I believe that Java provides better infrastructure for building enterprise-class applications than
- If you're using Java, don't blindly lock yourself into J2EE. That was my first mistake. I now use hibernate for my persistence layer instead of EJBs and tapestry is my web framework of choice. Hibernate is much easier to write (and especially test) than EJBs. Struts is an ugly crutch that completely breaks the OOP principle of encapsulation and JSF is the bastard child of struts, ASP.NET and some thalidomide.
Now you have a decision to make, and I'm not going to make it for you.
dont kid yourself about java. Secondly you have massive third party support with .NET, and very mature integrated IDE devlopment applications.
Before the pro-linux and anti-microsoft zealots attack this question from a biased view, I emplor you to make a swatch. A simple program with a few lines of trial code which will do the Exact same thing for each system.
.Net being insecure.
.Net framework, another software layer, every time you make a system call... which you (with a medical application) will be making more system calls than any other type of code. If you write some sample code... give this a shot. Neither will let you down for speed... unless you're running .Net on your main windows server, and you're Remotely running Java apps from a separate server... then of course .net will run faster. Put them both on the same machine and there will not be a noticeable difference for your application.
.Net is not insecure. Windows and Internet explorer may have many system holes not yet patched, and Microsoft is a bigger target for crackers (malicious hackers)... but that has nothing to do with the holes in .Net. Java and .Net are susceptable to a similar number of vulnerabilities if you are planning on running both in a Windows environment. .Net may be less secure if you plan on running either of them as a Web-based application and you're using Internet Explorer on the user's computers... but that's just plain stupid. Don't write it for Internet Explorer. Period.
The reason I feel you need to do this is to get out any negative notions of J2EE being slow or
First point: Throw out the assumption that Java is slow. It is interpreted, yes... but interpreted has nothing to do with true system bottlenecks. C# (.Net's native language) is also at the mercy of the same types of system bottlenecks. Java has to be interpreted by the virtual machine, a software layer. C# has to deal with the
Second:
Now I invite others who have dealth with both of these systems to give their individual advise, and even if they contradict me... but I always recommend being careful who you listen to. I'm not claiming that everything I've said is the end-all-be-all of the truth. No offense to the Slashdot crowd, but we can shoot ourselves in the foot sometimes with negative comments about Microsoft without backing. Those who back up their torts are often right... but please make sure they apply to you and YOUR application.
Just drop acid, already, and invent something better... or quit your whining.
There's an easy way of looking at this.
.NET, you're committing professional negligence. You're locking your client into an entire product line. To quote Gosling, .NET is a product - not a platform.
.NET will immediately limit their choices.
By building any application in
Should your client ever decide to move to another platform or seek an alternative developer to take care of the code base you're producing for them, choosing
I have just finished a project for small group physician practices all built OSS and 2005 I will be working on another project for the same market with .NET.
.NET is a very good environment to get large, complex applications built in with limited resources. I had never programmed in it myself until two months ago and I must say it is not difficult at all to pick up as long as you understand OO programming (which any programmer does).
As much as IO enjoy OSS and dislike the evil that is blah blah blah, I have to say
So my take as far as the market itself is that the best thing to do is develop web services that can be consumed by the customer. That way, the platform you develop in does not matter. If you have to pick, then know that Microsoft is making huge strides in healthcare with transcriptions, digital medical records, iPaqs and Tablet PCs. I don't see a lot of OSS in the market.
Best of luck.
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
I have heard MANY good things about Apple's WebObjects software, it's cross platform (OS X, Solaris and NT/2000/2003, maybe more...) and it's supposed to be a dream to develop for.
If you assume that the client will not care about the back end, give it a look.
The big problem you may have is any customer with an MS Enterprise Agreement. The unspoken rule with those things is that YOU WILL NOT run ANY technology that Microsoft does not make.
I worked at a client that had an MS Enterprise agreement, and the 15 person department I was working in had ALL Macintoshes, and it was funny how both the IT director and later a rep from Microosft came in to have a talk with me to see what the timeframe was for transition these people off of their Macs...
I was told that use of any non-MS products could affect pricing levels.
Bottom line is....
If you want the greatest coverage of customers, develop in J2EE. It covers you if you run into a shop with an Enterprise Agreement (J2EE will run on NT with IIS), and will cover you with a CIO that has a thing against Microsoft.
The other thing you have to realize is that doctor's offices are on a budget. You sell them a cheap Linux solution, and they'll be happy.
Bah. Use MUMPS, like the US Veterans Administration. It has all the power of BASIC with the transparency of INTERCAL. Who could ask for more?
Microsoft is to software what Budweiser is to beer.
The REAL question is what is the ROI on using J2EE vs. .NET? Which one will save you money down the road? Which one will offer you a support system down the road? If this is going to be that large of an application, which platform will be best for the hardware that you are serving (PDAs/PC's/etc)? Who is going to support this system once it's developed? How much post-development work is going to be needed? Would the customer rather be involved or let it plug-and-play? How much of an IT support system is going to be needed for this system? Which platform would be best for large groups? Which platform would be better for smaller groups? The customer most likely going to like the system that just "goes", besides the usual IT jobs of backups/etc. Which solution is more likely go get the customer to buy it? Do you want do make it so the customer would benefit from extensions to the product?
The other issue is risk management? Which system will likely fail? Which system will cause a rise in development costs that may have been avoided? Which system is easiest to develop on for your network? Which system is easiest to manipulate if the customer adds requirements as you go along?
The nice thing about open-source software is that you don't have to spend precious time and money re-inventing the wheel---you could at least improve upon an already existing design. That said, at least check out GnuMed. It doesn't have the backend that you're looking for, but at least will give you ideas. It's a system developed by physicians. Won't you consider contributing to a open-source project? It'll make the world better---at least with a unified open-source system, patients will be better-off due to ease of document transfer from clinic to clinic.
Linux at home
You know what? It really doesn't matter which you choose.
.NET side of things, and once Visual Studio 2005 is out, it's a complete no-brainer. Eclipse is the best development tool for J2EE apps and has excellent support for testing, in-code doco, and refactoring. .NET is far, far faster to develop simple applications, but they're roughly equal for more complex applications.
.NET or J2EE for this.
.NET path. If you're a mixed "one of everything" shop (like nearly every hospital I've ever worked in), spend the time doing a comparitive study. If you're going to sell to other health care institutions, stick to .NET.
... but RAM is cheap. .NET is faster for numerical computation, and database access (particularly to ADO.NET native providers like SQL server), but most health care apps are data driven, not computationally driven.
What does matter is the Sarbannes-Oxley and HPIAA acts, and think like as if your data was in there.
Patient privacy is all important, and that's 100% about process and 0% about technology.
Spend the time to create the system properly.
Think about the entire lifecycle
- architecture
- design
- testing
- coding
- SQA
- Security / UAT / SIT
- Deployment
These things are important. Do not fall into the waterfall lifecycle methodology - it's simply too hard to deliver secure code using it with excessive caution on the risk front. Use an agile process instead.
When you come to the coding aspect, the tools are far more mature on the
In terms of security, both are reasonably secure unless you decide not to be. I heartily recommend the "Writing Secure Code" book by Howard and Le Blanc, and of course look at OWASP's output.
I train developers to write secure code all the time. My main advice is to Think Evil(tm). What could you do to subvert the code you're writing.
Go to the place you're writing for - most of the time, it'll be terminals in semi-public spaces. Look at how the staff just leave the computer unlocked, and yet how well they look after the paper records. I don't know why this is, but you as a designer MUST cope with this human behavior. There is no class in
For cost reasons, if you're a Windows shop, you should go down the
The primary reason for security failure, availability failures, and other cockups is human fallability. If your code is the difference between a manual process which is (say) 40% slower than the automated version, that's 40% of patients who cannot be dealt with during an outage. People could die. You MUST be servicable and supportable. Your in-house skills dictate this choice, not platform or one-eyed "X is crap" choices. You could be the one or two that die.
As for reliability of the platform, in my experience, both are equal in the hands of well trained staff. J2EE is more memory hungry
As you point out, Java is cross-platform, but in my experience with several large scale applications is that developers get lazy and tie you to middleware instead. Some of that middleware is not platform independant, and you're stuck on a crazy combination of platforms occasionally. Also, unless the developers use Windows to develop and test, and Unix to develop and test, it's 99% certain that the code will not just run on the other platform. This is true between deploying (say) AIX on Websphere and Linux using Tomcat just as two examples.
Unless portability is more important than all other business drivers, do not include it in your list.
Remember:
* patient privacy #1
* correct operation #2
* availability #3
The rest will fall into place. You could satisfy my top 3 health business drivers in Coldfusion or PHP. It's not about the technology. Decide on your patient's needs, not yours.
Andrew
Andrew van der Stock
Just want to put my two cents in here. I am the developer of a product which is a hosted application. Being a bootstrap startup, we had to be careful with our budget. I was already experienced with Java and wanted to continue in that world leveraging my skills. After much review I came upon WebObjects. The price seemed right and I was just getting into my Apple OS X laptop in a big way. Well, I can't tell you how amazingly productive WebObjects turned out to be. And!, I can deploy it on WebSphere or jBoss too! WebObjects runs the iTunes store so you know it can scale and the price was right too...$699. Finally, I found the community to be extremely helpful. The final upshot of all this is that I am single handedly the developer and system administrator of a couple of XServes running WebObjects and mySQL currently getting the application IBM certified with DB2 and WebSphere. This with just one code base that detects the database at runtime. WebObjects is an outstanding product.
Mind | Body | Spirit | Cash
I'm not really concerned with the accuracy of the information, or unfinished entries. Cause eventually, someone will fill them in, or correct them.
I'm more concerned about the fact that their site currently isn't browser friendly with all broswers.
Entered in wrong article obviously.
-- Ignacio Valdes, MD, MS
-- Editor: Linux Medical News
http://www.LinuxMedNews.com Revolutionizing Medical Education and Practice.
I don't think I've seen as many Anonymous Cowards pluging^h^h^h^h^h^h^h^h.. er.. suggesting thier products. :-)
"Enjoy what you're doing! If it becomes drudgery, you're doing it wrong!" - Jim Butterfield
I cannot give you an answer for your particular situation, but I can tell you my opinion, based on my real-world experience.
I am the chief architect for a major application developed by the U.S. State Department, and used by foreign governments for the licensing of hazardous materials.
We use J2EE, and have been since 1999. JBoss is our application server. We used to use Weblogic, and were technically happy with it, but JBoss does everything we need, and has licenses and costs more favorable for our end users.
Our application is a bunch of domain objects and custom business logic, presented by the J2EE server as a bunch of sessions beans (some stateful, some stateless). We have a swing and a web-based client. Most of the rich interaction is done with the swing client, with mostly browsing and canned searching from the web-based client.
We do NOT use Entity beans - and I don't suggest anyone use this part of the EJB specification... For data persistence we use The Versant Object-Oriented Database. For data persistence, I'd recommend this, JDO, or Hibernate talking to the relational database of your choice.
We are very happy with the choices we have made. There is a TON of information out there about J2EE, we are happy with the performance we get, the skills are readily available, and there are plenty of vendors building tools in that space. J2EE is obviously a realistic choice for the kind of work you are doing - and has been for many years.
I do not know much about .NET... only because that isn't where my career has taken me, not because of any dogmatic stance. My major concern about using it for this kind of work is that there is no 'application server'... .NET is tied to the windows platform. I know there are projects like Mono, but realistically, if you are using .NET, you are buying into Microsoft, their tools, and their solutions. With J2EE, I can upgrade my operating system and my application server independently - choose from different vendors for both, play them against each other for cost/support benefits, etc. With .NET, you just won't have these long-term options.
I am the president of the Northern Virginia Java Users Group. While some may say this makes me biased, I'm not an employee of Sun or anything... I work for a relatively small company. I am involved in the NovaJUG because I happen to know and like Java, and like to teach. I also occasionally speak at conferences such as the No Fluff, Just Stuff Software Symposiums. I'm not going to leave my email address or anything, but there is enough info in this to track me down. IF you would like to discuss this further, drop me a line.
The McKesson Horizon suit of products (clinical) all have a J2EE future. Right now availability is a top concern for those of us deploying clinical systems and evaluating vendors. A portable solution is important here because it allows the IS shop to determine which scalability/availability solution best fits their budget.
I like Java better. I have been developing, maintaining large scales applications from a Canadian provencial Health for four years. There lots of thing make me wonder how .Net deal with it.
Plant form. We have to deal applications that writen for the whole country. If it is a .Net app, we will have to install a MS server and install it. Fortunatly that app is a J2EE application. It is not hard to deploy it to WebSphere.
Development environment. We are not stucked on one tool, one OS.
Open source packages. We do reports by using jasperReport. It used to be Cognos. Bloody expensive and the solution is way to heavy and it made one app have to crose two type of plant form. We also have a bunch of mainframe application need to be available on the internet. We used an open source 3270 simulater to do the screen scraping.
As other said, it depends on your teams experience on Java and .Net, the requirements. If all the above items do not matter to your project, the decision will be easy to make.
If you are creating fat clients, .NET is the way to go, most likely. If you want web based, J2EE has a lot of open-source compenents you can use to get your application networked via HL7 .NET nor J2EE, rather it is PHP/MySQL
HAPI is a java-based open source HL7 library:
http://hl7api.sourceforge.net/
JEngine can quickly route HL7 messages to & from your application:
http://jengine.org/
If your software is open source, or you can use open source components, OpenEMR can give you a leg up for clinical demographic and medical data management. It's neither
http://www.openemr.net/index.php
If you will be interfacing to large hospitals or medical centers, you will most likely bump into Cerner http://www.cerner.com/ or McKesson HBOC http://www.mckesson.com/homeflash.html. While these companies are a bit out of scope for your question, you might want to reserach them as they are the biggest players in the field. Good luck, it is an interesting time in the health care IT field.
development is having someone who knows HL7 inside and out. Do NOT think you can learn it as you develop, you can NOT. It fills 2 binders, each over 1000 pages. I had X12 experience in the mortgage and finiancial industries. When I went into medical I figured it would be someting I could opick upo as I went. Lets just say I'm glad they didn't make HL7 my top priority right away.
.new excludes more platforms the J2EE, however, most hospitals are tied into Windows.
As for your development platform it comes down to this:
the only caviet is that there where some discussion about MS OS not being able to meet the HIPPA security requirements and still be usable in a practical manner.
Now I haven't developed medical software for about a year. If I were to get back into it, I would look into windows OS security complaience and call a few hospital IT dept. and see what they think, and what is on their road map.
The Kruger Dunning explains most post on
It'll give Java and .NET a run for it's money.
Too bad it's not done yet.
I work with big db-based apps. Here's a sketch of our architecture : Klocs and klocs of screen support code. Basically, we can design a screen with some basic layout resources and some meta data and have fully functioning new/edit/delete functionality for records and subrecords. This type of functionality covers most data entry. Custom app server. Setup as a service, any long running or schedulable jobs like db cleanup, data warehousing, long running queries can be packaged up in a batch object and scheduled off for either immediate or delayed execution on an app server. App servers talk to a scheduler database and are limited only by the number of machines and how much horsepower the main db has to supply/process data. Logging and debugging. The haystack comment somewhere above was great. You can't build a big system if you can't debug it. You need logging, process tracking, process monitoring, process reporting, sql tracking ... you get the picture.
Anyway, good luck with whatever you try to build.
Suddenly the "Blue screen of Death" takes on a whole new meaning....
Cat: The other white meat
Java isn't slow. Honest. And .NET is just as cross-platform capable as Java is. In fact, it even allows you to cross language barriers so code can be written in whatever language is best suited to the task. Technically, Java can do this too, but it isn't as well done or publicized...
No comment.
webapp, webapp, webapp.. if you need a "rich" UI 99% of the time you're probably putting bells and whistles on a rat. Users want functionality not some snotty NY designer's wet dream.
.Net crap to deal with, thank god. BTW the system is *FAST*, Hibernate is a godsend. No client prereqs, just a browser, firefox please, and the users love it. .Net?? I thought the big boys gave up on that ASP/VB mangled garbage years ago... who knew?
.Net failures, it makes me smile. tnx Bill!
Java using Struts, Hibernate, Xdoclet, Spring.. all open source treasures.
We developed a large inventory, client, and server management system in a matter of weeks not months. Pick a Java app server & a database, drop your WAR file and you're done. No
Actually.. please disregard this post, I love presenting clients with apps that run circles around the piss-poor
i work for a company that develops Rx systems for hospitals. We faced same design decisions, so here is what we found: if your product is going to interoperate with other healthcare software, you will probably have to work with HL7 (the standard protocol for healthcare data exchange). The easiest we found to do that is BizTalk 2004 with HL7 accelerator (yes, both are Microsoft products). So .NET was the natural choice for this component.
The rest of the system components are written in Delphi though, so you might want to consider this one too as a grat RAD tool.
Good luck!
Hmmm..
.NET, and by-and-large, this seems to have been a successful gamble, though not a smooth road. The Eclipsys flagship product, Sunrise XA, is written almost entirely in .NET. This product is a major player in the healthcare arena.
This is an interesting question. I'm actually in this industry, and have been for the last half-decade. For an industry that seems to lag remarkably behind the times, I'd like to note the following:
1. The major player in this field, McKesson (previously HBOC) seems enamored with Java. This, however, is only because the Healthcare IT field seems to be 5-15 years behind the current technology.
2. Major players in this field (Particularly Eclipsys) have bet the farm on
3. Many hospitals have strict rules on what IT software is allowed. I will tell you that the following is ALWAYS allowed: Windows NT, Windows 2000, Windows 2003, SQL Server, Oracle.
The following is SOMETIMES allowed: Sybase, Any "other" RDBMS, Windows XP, Linux, *nix, etc.
With the combination of Windows and SQL Server, you can't go wrong. Don't believe me? Do your market research. Want more info? jerry@dennany.org.
First of all, you WILL NOT get the gains of GUI development in .Net web apps that are promised to you. That has been proven out at a project at my own workplace. Yes the demos look very good. But for a system with any degree of complexity beyond a few form fields you are going to be doing a lot of monkeying, and not the fun kind. Java is still far ahead in terms of framework richness.
.Net question look at the maturity of software for the two spaces. Java has multipl mature IDE's, multiple mature monitoring packages, multiple mature performance tracking packages - you get the idea. Yes I am biased, but ask yourself why you would use a clone when you could use the original which is still advancing? Why settle for one app server that runs on one system when you could choose from multiple app servers that each run across multiple systems.
Also, when considering Java look not at just J2EE, but other systems coming out like Spring. Note that Struts is now very widley used, very stable, and would make a good choice (possibly in conjunction with Spring).
Lastly, when considering the J2EE vs
"There is more worth loving than we have strength to love." - Brian Jay Stanley
This is /.
.net. They do not decide these things lightly, folks.
Anything related to MS is not well-recieved.
Har har, good one, but try again: This is slashdot, where most of the audience are microsoft windows users. Looking over the posts so far, I see a fair amount of comments from microsoft fans fans chiming in with all the reasons to standardize on dot net...
FWIW, I work for a major (and I do mean major) automotive manufacturer, and they've recently decided (and announced to the IT staff) that the architectural direction for all future enterprise apps is to be j2ee, and not
Most medical practice management/payment software is pretty much database-driven. The challenge is in keeping up with new business rules which come out quarterly. Personally my goal is to have a unified software base which embodies medical billing and payment. Imagine software that bills and pays in the same model. I'm talking ANSI X.12 with all it's sub-formats talking together as they were meant to be..
I actually designed a practice management system database from scratch. to do so for a payment system too is just the next logical step.
The language is the least of your worries. I would strongly advise against
Python is getting more and more credibility in Healthcare and Scientific computing. Its fast, easy, stable, and secure. It would be a very smart move to use Python.
Your real focus should be HIPAA compliance. If you don't know what HIPAA is you shouldn't even have this contract, but assuming you're not going to just "give up" you should read up and become informed on HIPAA. This is assuming you're doing the work for a Healthcare provider in the US that is... anyway, HIPAA regulates healthcare software... if you don't meet HIPAA standards for security (not only coding wise but access wise etc) your product will be useless and you'll be forced to redo it... more importantly... you'll look like a group of idiots.
So yeah, start reading up on HIPAA (It takes months to understand it all if your not fimilar with it at all, so I wouldn't waste any time.)
I had to reply, considering all of the responses I saw around PHP.
Not to slam PHP, it most definitely has its place, but enterprise healthcare is NOT where it belongs.
We provide an ASP model for our clients - approximately 4000 users total. We generate 4-7 Gigs a day of electronic medical records - radiology scans, dictation, transcription, faxes, documents, charts, etc. I for one would NOT trust PHP to that kind of role. We currently have close to 14T of data online for our clients.
Our software suite is entirely web based, hosted on linux based servers. Its not PHP, its not ASP, its not java. I can't speak for java directly, but I know that PHP could not scale that well to serve 4000+ users.
Its a hard market to get into, and if you're on Slashdot asking for advice for this, you really need to do more research - and not on Slashdot.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
I am currently working on a project for a software company that sells to the health insurance industry.
In developing this project I've had contact with a lot of the largest health insurance companies in our region.
What I have found most of them have in common is a mixture of J2EE and ColdFusion, almost exclusively. It appears that dotNet hasn't made the inroads with the health care industry that they have with other corporate clients.
Holmes
...you're hopelessly outclassed by those of us already in that space.
Deciding on a platform is a trivial issue. Deciding on your system architecture is the key question that you should be asking. Forget .NET and J2EE for a moment. In any case, deciding on .NET or Java first, and then building your system archtecture would almost always result in a poor and non-optimal design.
.NET or J2EE now becomes a trivial issue. In fact, you can even have both, with additional platforms thrown in.
.NET or J2EE or whatever.
Take the bottom-up approach instead. First decide on the database that you're going to use. Consider your database size, performance requirements, transaction requirements, and reliability. Get a database expert or DBA guru on board, if you don't have one already. Believe me, this is the key. It's no secret that most enterprise systems invest the lion's share of their project budget on their database architecture and personell.
Next, make an estimate of the business logic complexity and size. Consider implementing the business logic directly in your database. The advantages of doing this are:-
1. Performance - No client application or middle-tier server application can hold a candle to the performance offered by a well-tuned stored procedure or (Oracle) package.
2. Maintainability - Say, you have a thousand clients connected to your database. Changing a business logic component that's implemented directly in the database would be a trivial issue. Change the package and recompile. Clients can seamlessly get the update.
3. Simplified system design - As long as you have a strong database architecture, you'll notice that the complexity of your non-database code will be dramatically low. In other words, taking a decision on a client platform such as
4. Portability - Again, because your biz logic is encapsulated in your database itself, you can have multiple client technologies connect to your database in a trivial manner.
5. Interfacing with other databases - My experience with enterprise databases has shown me that interfaces cause 80% of the maintainence issues down the road. As opposed to these "platforms", most databases offer readymade tools for scheduling and implementing interfaces. Again, no command line interface or XML web service implemented in a "platform" can even come close to the performance and reliability of a database level interface.
To reiterate, your first three criteria on implementing a robust system design should be database, database, and database. Remember, the lifeblood of any software system is its data, not the cruft we call
Although I've titled my subject as Oracle, it can be replaced with any other RDBMS that suits your needs. Only, remember, nobody ever got fired for implementing Oracle, and for good reasons to boot.
Sun occasionally talks about releasing Java so you could use it; but so far it's been all talk, no action.
My vote... Ximian-Mono
From what i could get from the article, you first must determine what exacly is your software going to do.
...
.NET well, my understanding is that the problem is Windows. Can you afford to have your application to crash? Is the possibility to "lock" the station important to you client? If no, then windows could be a good choice.
.NET or J2EE.
Handling shedule? Monitoring medical equipment? Issuing medication list for patients?
SUN clearly state in its documentation that J2EE is NOT for mission critical applications. And if you have hardware interfaces to program, Java is not the programming language you want. In other hand, if you are only going to work with a database, then yes, an interface that can handle any platform is best.
As for
The choice of platform is only secondary in your case. First get all the specs out, especially security and safety related specs. Then choose whatever platform that does the job, don't just limit yourself to
As bad as your grammar?
Your pissant little 4000 users total is what significant PHP sites handle each minute! Oooh 14T :) That's only 14000 of the millions of email accounts significant sites handle.
If you think PHP can't handle your dinky little requirements, you know very little about scaling systems. What, you think the guy's going to run the whole thing on yor mom's Pentium II?
Granted that's a worst case, but you never know with Microsot.
Free Software: Like love, it grows best when given away.
My healthcare toko was a Microsoft house.
The results were various. Every virus went through the whole hospital, and somehow it invites the more sloppy third party providers. OTOH that may well be because the package selectors only look at the looks of the app, not at the problems.
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
OpenEHR uses open-standards based archetypes as "flexible easily understood templates" for specifying complex systems that are inevitably going to evolve overt time - as health systems always do.
Thomas Beale is lead on the archetype work,
Artificial intelligence is the study of how to make real computers act like the ones in the movies.
I will admit upfront that I am biased. I am a Sun certified Java Programmer, working on Developer. My C#/.Net experience is limited to reading a book and talking to friends who are currently taking a course at Uni.
.Net might have the advantages of:
As you can probably guess, I'm going to recommend Java. The technologies are very similar and it is probably not a great problem whichever you choose, but in my opinion Java has this going for it:
-It has been around longer, which means more people are familiar with it and it has time to mature.
-There are a huge number of tools and libraries available. The best ones are being copied (NUnit from JUnit etc) but there are many more.
-It doesn't have MS behind it. Those who don't think MS are going to play the lock in game again if things are going bad for them, are terribly naive.
On the other hand,
-As a newcomer it can avoid some of the mistakes that Java did and is stuck with.
-It has the massive resources of MS behind it.
Being bitter is drinking poison and hoping someone else will die
First, asking a web-based community like /. for opinions about platform is just a plain waste of time... and of course that's why I have to respond and waste my own time.
For all you Java-heads out there bashing .NET, take a good look at all of the wonderfully-slow Java apps that take 3x as long to develop and suck because the JVM takes up half of any machines RAM just to get rolling. Acceptable on a server - maybe. On a desktop? No.
If it were up to me, I would centralize this app using web services making it possible to use whatever the f you want on the server, and then go with .NET for the desktop apps. If you were to use MS on the server, you could even use .NET remoting.
My final opinion: you're screwed if you're asking this community for platform decisions. Take some CS courses - preferably some that deal with development life-cycles.
Zope and Plone is the way to go. These tools are RAD for the web, you'll have to learn them, which is hard, but then I guarantee that you'll save LOTS of time !
Votez ecolo : Chiez dans l'urne !
We are using Java because that's what we do and because it's platform independent if you're careful. and then we publish C++ or .NET bindings for the customers who are using the other languages or development platforms.
We use Codemesh Juggernet and Junction products and they work very well. They use JNI on the client so you need a JVM there but they are much faster and nicer then using webservices. These tools are not free or open source, but codemesh offers an optional commercial source code license. We saved a lot of time and money by using the tools and we are still saving because we can easily regenerate the bindings each time we change our Java product.
I believe that Java is the way to go for development but that doesnt automatically mean that your product can only be used by other Java developers. Codemeshs products worked well for us but I am sure there is a variety of other products available that solve this problem. We chose Juggernet and Junction because we liked the performance and getting everything from one vendor and because the support is good.
Have a look at Komodo by Activestate.com (you can get a free trial version for 30 days) or sunbird (mozilla calendar), firefox, thunderbird. they are all based on gecko: write the UI in XUL, a XML language, and the logic is implemented in Javascript, Python or C++. These languages can be mixed with XPCOM, the Cross Platform Component Object. the server side logic can be implemented with java or .net (i would prefer java for servers, so you don't depend on M$), the protocol can be SOAP, XML-RPC or simple HTTP forms.
Why develop for a specific language?
If you are currently a Java shop with no .NET experience, you will most likely fail with your first .NET project, unless you bring in some experienced mentors. And vice versa, of course.
With the right experience and good project management, either technology will succeed.
Great Windows SFTP Server!
Both .NET and J2EE can be made to work. In the UK (where I live) the National Health Service has launched a programme to provide nationwide healthcare record integration. It's going to be expensive (around $6bn so far and some projections estimate a total cost around 10 times that). However, it'll be the first such system in the world and will have useful patient benefits (e.g. get admitted to A+E - the ER for US folk - and the doctors there will be able to access your medical notes even if you've never been to that hospital before). More detais of the programme here and here.
.NET, and the national facilities (which provide services for all 60 million patients [approx]) are mostly built using J2EE on Oracle on Solaris. At the moment, the middleware is SeeBeyond e*Gate.
.NET 1.0 with other things using SOAP - it doesn't seem to interoperate well. Maybe that's fixed now though.
As for what technologies are in use, the local service providers (of which there are 5 with about 12 million patients each) are mostly using Microsoft-based solutions, mainly written in
Speaking personally, I have had difficulty integrating
Than please use neither of them!
medical mafia, i.e. selling expensive drugs that do not cure but only relieve symptoms for a while, is not healthcare to me. I hate this kind of amalgam ... grmbl. I prefer natural and holistic healthcare, a bit more interesting to me, and it does not require expensive software. Please use technically-precious technologies like J2EE and .NET and their valuable technicists for more appropriate purposes.
I think you need to understand some more options about the audience you will be dealing with. Not only at the client level, but at the larger architectural and business operations levels.
As for the software considerations, It's very possible to find examples of fast/slow, secure/insecure, java/net applications that will serve everyones examples. The point on this is you can find good/bad developers for any software platform. Remember that you get what you pay for.
Getting back to the Health Care System. You remark that Hospitals are the audience, but are they the only audience? There are also some massive security requirements that you will have to address. If you can't meet these government regulations you simply won't be doing business with anyone.
The Health Care industry, despite it's spiraling costs as experienced by anyone needing services, does not give software systems a financial priority, including OS upgrades.
Whence? Hence. Whither? Thither.
I guess the program is started with insufficient memory for the task at hand, or it is written to use a random acces file or something, killing performance that way. Type "java -X" for info on memory configuration at startup of VM
Mono reached 1.0 only very recently (July-August), and I'm not aware of any significative medium to large deployment of production-quality systems based on it yet. Java is a mature and proven technology, and while it has its problems, equalling Mono to Java in terms of viability, as of this date, is IMHO overstretching Mono's virtues.
I would rather wait until Mono matures before risking a deployment on the healthcare industry.
You're bound to be unhappy if you optimize everything. --Donald Knuth
Seriously. On the java side you get immense complexity, and on the .net side while all of the choices are made for you, there is still a lot of complexity. Either platform requires a lot of tribal knowledge to get started with.
.net/java.
If at all possible look at a PHP web-based front end. The interface can be tricked out with some nice javascript style features (e.g.: google gmail) and keep your back-end database interface open, so you can bundle postgres for free, or they can use oracle/db2/whatever if they want to.
The big win for PHP is time to market -- you can cobble together an app _very_ quickly by avoiding the 3-6 month j2ee/.net learning curve. It also lets you be more price-competitive since you can deploy it on a really inexpensive platform. So if your competition quotes $50,000 which has to include fast servers (.net is just as resource hungry as java), windows licenses, database licenses, and several additional months of development time, you can quote $40,000 and still have a bigger profit margin since you don't have the higher-cost platform.
Make sure to offer a 'reporting' module that is basically a $500 copy of crystal reports with a bunch of reports you've developed -- don't fall into the "I'll roll my own reporting engine" trap.
If 'rich' interfaces are required, don't discount javascript, xul, or even flash -- all of which eliminate the 800-pound gorilla that is
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
Go J2EE.
Period.
First of all don't use EJB's unless you have to. If you don't need distributed transactions then stay away. You don't want heavy weight frameworks to drag you down. Read: Better, Faster, Lighter Java. http://www.oreilly.com/catalog/bfljava/ For a free introduction read: http://www.onjava.com/lpt/a/4744
My personal advice is a stack made of:
- JSF for the webfront. Struts if you are a bit more conservative. http://struts.apache.org/
- Spring for the business logic. http://www.springframework.org/
- Hibernate for persistence. http://www.hibernate.org/
If your need a thick client then use Swing instead of JSF. Then you can stick RMI in between two of the layers.Don't forget to have fun.
TCAP-Abort
I just love that Neil Young classic "Southern Shop". Hope Skynyrd doesn't retaliate with "Sweet Object Oriented"..
-- jimmycarter
Pulease! grab a sexy Opteron server from SUN, grab the SUN Enterprise System Software; includes everything you need for night of fun and excitement.
Voila, for $100 per employee, you'll have a app server, web server, directory server, messenging, collaboration and mail server.
G.
For S390 based host systems (IMS, CICS) there are J2C adapters. IBM and 3rd party.
Of course we have no idea if you need such a thing for your product.
TCAP-Abort
If this was in the Uk, I'd vote for a portable solution because I don't want anything tied down to one vendor. ESPECIALLY in government/services.
M
I work for a healthcare company, and I have one piece of advice:
Focus on telling the customers what they want to hear. Better patient care, increased patient load per employee, better morale among clinical staff, etc.
The specific technology used is meaningless to them. And since healthcare lags so far behind any other industry, you can clearly see the next five years of what they'll be using for infrastucture right now in other industries.
Retired from software... maybe. Sort of.
So i know to avoid those hospitals..
I dont want either to be used in my healthcare products.
Id prefer something stable and secure if my life is relying on some piece of software..
You wouldnt see either of those in my anti-lock brake controller.. Think along those same lines.
---- Booth was a patriot ----
I have been checking the thread and I have seen several truly insightful messages regarding a topic that could appear trollish and dry in principle.
IANAL but write like a drunk one.
If you're developing J2EE applications, you are taking about server side development, what does .NET being on the desktop of people's computers have anything to do with your problem space? I would say your very senior manager doesn't understand application development/architectures.
A little off-topic but still salient to the discusion: In your post, you don't say what country you live in the south of. If it's the US, be aware that there are two sets of rules that your software will have to live under. HIPAA of course, deals with access to protected medical information. 21CFR11 deals with software as a "medical device" and in many ways, is more difficult to work with than HIPAA. The problem with 21CFR11 is that it's a moving target without real specific rules.
The main things to keep in mind are version control, encrypted signatures, audit trails for everything, access logs for everything.
wherever I go, there I am.
Having just graduated from software engineering I can tell you the answer to your question. The answer is, is that there is no answer. We have no idea what the project is about, what it's supposed to do, the requirements, or anything. The only thing we know is that it's for the Medical domain. Anyone who gives an answer to this question has no idea what they are talking about.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
I've built two applications for johns hopkins cancer center and they've all used mozilla. The nurses on the floor love the applications. They support printing and the controls are fast and highly usable. Putting the applications together was a snapp because of how easy it is to build applications using the mozilla framework. I think once xulrunner is here more people will start seriously considering mozilla as a framework, but why wait. The only thing you need to do today to start using mozilla as a development framework is download firefox. To start your own app just run firefox using the following:
firefox -profile yourprofiledirectory -chrome chrome://myproj/content/
setup your installed-chrome.txt
put your chrome files in the path referenced in installed-chrome.txt. Write a simple batch script for calling firefox or put it in the short cut, either way. Or write your own exe to start firefox.
xul, js, and c++ the best of all worlds, scripting, xml, and high performance C++
I have heard stories of MS products concatenating records in a medical environment. The scheduled breast implants to an 85 year old man in for bypass surgery didn't happen, someone noticing unusual record mismatches with the patient on the gurney...
whatever is decided, Flag in RED possible problems and database sanity check failures. Write as if you are addressing someone who has english as a second or third language. Put the time critical information FIRST. Get real EM staff ( doctors, nurses and the technicians that would usually never see a live patient to check for clairity on the screens, reports, tickets and the importance of which procedure to do first.
A simple test - standard procedure involves taking the blood pressure and pulse. There is bright red blood on the interior thigh. Should you follow standard procedure, or check to see if the femoral artery is cut. Time to bleed to death from such a cut is about 7 or 8 seconds, depending on severity.
And your choice is??
This is progress?
BSD is UNIX. Linux is a UNIX work-alike and, for all practical purposes, the same as UNIX (but SVR5 instead of BSD). There is a great chart showing the history of UNIX at http://www.levenez.com/unix/.
The US Dept. of Veteran Affairs, which comprises hundreds of hospitals, is developing in J2EE for their future integrated health care system. Mumps is out; Java in.
Check the web pages. Find an email address and ask them. They have a PKI section in their IT Division (PKI in ITSD).
On that note they also have a careers page :)
You have a sick, twisted mind. Please subscribe me to your newsletter.
That has to be some of the biggest spewing of bullshit I have ever heard. I work at Microsoft, in particular in dept that deals with .Net success stories, and the situation you described has never happened anywhere.
Asking the slashdot crowd whether or not to use a Microsoft product is kind of like asking a large group of people whether they'd prefer to have sex with beautiful women, or stab needles in their eyes.
.NET, I'm not very partial to Java either. I'm pretty sure this is just another excuse to bash Microsoft.
Sure, you're going to get a few who will take the needles, but you already know what the vast majority is going to say. While I'm not a fan of
BeauHD. Worst editor since kdawson.
Furthermore, Java has signifficant support from other industry leaders (like IBM) with significant patent portfolios. This means that, if Sun ever did try to play nasty, the other companies who are in the Java market would probably get just as nasty in return.
The net effect of all this is that, while both Java and .NET are patented in their various parts, the probability of getting hurt on Java patents is much less. Or, put it another way, Microsoft is evil, and you shouldn't sell your soul to evil. It's bad form.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
As a .Net developer myself, I endorse it over J2EE. Compatibility and ease of maintenance are the main benefits. The ./ community can't diss .net, just look at the Mono http://www.mono-project.com/about/index.html project. C# has actually gained pretty good legs as a language standard. It even has ECMA http://www.ecma-international.org/publications/sta ndards/Ecma-334.htm certification, which DOES mean something.
Curious. Why J2EE?
Over the years, I have discovered somthing. Java programmers love frameworks. Too much. Ditto for elaborate libraries and APIs.
So, when a Java programmer working for me trots out some bit of framework pixie dust, such as JAXB (which is cool, I admit), I've learned to say: exactly what is this going to do to pay its way IN THIS APPLICATION AT THIS TIME? Is this the simplest way to deliver the required functionality in the current or next delivery? If the answer is no, then my response is that if you design your code well, we can reuse it with that library/framework/whatever when that framework is able to justify itself.
Java programmers often have a morbid love of complexity. Indulge that love, and an application becomes a morass of libraries (excellent though they may be) that force on it an incoherent mass of conflicting paradigms. The excellence and breadth of the resources available to the Java programmer are a strong argument in Java's favor. The inability or unwillingness to use these resources wisely is strong argument in dot Net's favor.
Keep things simple and focused on customer requirements rather than products. IF in that context, you can DEMONSTRATE that some PART of J2EE is a good starting place for this application, by all means use THAT part. DON'T take the entire J2EE platform as a starting point and then feel obligated (or even entitled!) to use every piece of it.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
1. Speed .NET applications can be natively compiled for Windows.
.NET are memory hoggers (unless you decide force a native compile).
:)
In terms of speed, you can natively compile Java; but I am not aware of any software that lets you do that for Windows (J++ doesn't count).
2. Cross-platform (compile once, run everywhere)
Java's JVM is an odd beast: each JVM behaves differently on each OS. A java application that works beautifully in Windows is not guaranteed to run as you intended on Linux.
3. Both JVM and
4. You don't want to sell a front-end written in Java to a Windows user that uses Swing. There are good java frontends, though: Eclipse, and Azureus, for example.
5. If it were up to me, I'd write everything in C++.
I'd suggest checking out some existing open source EMR/PM solutions already in existance. Including (but not limited to) OpenEMR, FreeMED, Care2x, TORCH and Vista. Vista especially, it's developed/used by the VA. It was recently opened up and the small office version is currently in beta. Check here for some more info.
http://www.linuxmednews.org/
Don't forget HIPAA! Make sure all developers go to at least one week-long security programming course before commencing work on the design for this application. That may actually help make the decision for you, since there are outstanding security issues for both J2EE and .NET - at least you'll know what you are getting into.
Remember that you can (and will, if your clients have any sense at all) be held responsible if your application doesn't conform to HIPAA requirements for data protection and integrity. That is a large burden to bear, believe me.
I don't see any mention of a web application in the question.
.Net is... Microsoft, and Python is just totally graceful.
I think that Python would be a *very* good option. Java is ugly (Yeah, I know, stating this is asking for Troll mod points from the java fanboys.),
With wxPython, you can build cross-platform GUI application very easily.
I must say that I'm totally biased here. I made the leap into python/wxpython 3 weeks ago (I used Delphi before that), and I absolutely love it. You don't know the joys of programming unless you tried the list comprehensions of python ([func(x) for x in y if cond(x)]).
And I never liked Java nor C.
perception is reality
If your team has never worked with J2EE or .NET, I'd say just pick one and stick to it. Technological details aside, if you are good with one, you'll be good with the other. Choosing one over the other won't kill you. What can kill you is either one of the following:
Don't fall for the trap of this platform over another one. Once you pick one, you may want to dedicate one or two of your team to really dig the living crap out of it, and understand its power and limitations. The rest of the team should concentrate in getting all the other crap right - requirements, SLA's, establish good contacts with user's liasons, internal development/testing/release/maintenance procedures, etc.
One thing above all (which a lot of folks forget) is to understand how the hell you are going to deploy and maintain your solution for a given client. Lots of folks develop the coolest solutions in J2EE and .NET, just to find out that they can't deploy and maintain the sucker without lending a kidney.
Do that, and you should be fine. As for job marketability, either J2EE or .NET skills will do fine. What matters is not so much having J2EE or .NET skills, but solid software engineering/architecture ones ;)
Peace and merry xmas!
- Moi.
When developing code we often forget the longer-term impacts that often hinder us later.
Take Java versus .NET. If I develop in Java then I don't have to worry about doctors who might want to use it on a Apple OS/X. If the world goes Linux it runs on Linux. Or perhaps some new tablet PC is running BSD or Linux. It may not even seem important now but going .NET limits you.
Very few programming projects are truly unique, as they often borrow source or copy the logic of existing systems. Would it not be nice if you could share the source code between Windows, Linux, OS/X, AIX, Linux, BSD, HP-UX and Solaris? If your shop only runs Windows now can you say this will be true for 2, 5 10 years down the road?
Even if you are a Microsoft only shop, you can borrow source code from Open Source Java Linux projects to help with the coding. .NET does not allow you this.
Having such a broad range of platforms it runs on generally means the programmers are more skilled and more source code is available. More skilled programmers often produce programs that crash less lowering maintenance and increases user service. .NET does not offer any of this.
Why .NET then? It's best redeeming value is that it takes lower skilled programmers and locks in that you must use Windows to run it. Although the product is OS bound and perhaps even less reliable you may have the skill sets to do it faster. If Microsoft jumps the price of their products you're stuck with it as you would not want to pay the price of re-coding all your projects. Techno-lock in if you will.
In a hospital, information security must be an issue. If you go just by the numbers on CERT or other vendor independent source .NET and Windows itself are relatively insecure when compared to other options. Java is by no means 100% secure, but at least it began its life with security as part of its design. In Java, security was not an afterthought or refit.
Historically languages like Java will last a lot longer than .NET. This lends longevity to code and effort. From your career point of view, would you rather hedge your skills on something that is OS independent or sink your precious learning time into a vendor slotted technology where if they fail you have to re-learn something else. We often forget it takes years of effort to become really good at a programming language.
Java offers a lot. If your manager does not use Java over .NET then he should have to back it up with some good reasons beyond his knowledge that one of his mutual funds just happens to own some MSFT stock.
We are a financial software shop and we have used it to developer real-time trading applications.
java slowness argument is very old fashioned. Unless you are talking about embedded mission critical military apps, then don't even let the slowness argument come into the picture.
insightful, practical advice from experience.
You can tell this topic was created by someone without the proper tools to implement a Healthcare grade system for their uses. The healthcare system is _very_ strict. The only department more strict than the healthcare department is the Department of Defense.
.NET would never be used on these sorts of real-world government industry. .NET and J2EE is usually done by people in the faster-paced industries like web design, internal IT projects for small/medium companies and pet projects. The normal XP style programming that is used in J2EE and .NET is _not_ suitable for a healthcare environment. You have to be HIPAA compliant. This is not possible with the XP style of programming, since you will not have the fast release cycles necessary for XP programming. It will be one large rollout, and a massive retraining for all the healthcare employees.
.NET or J2EE. If you really wanted my vote, I would vote for Ada.
That being said, the Department of Defense has a strong predilection towards Ada. This is due to Ada's overly-typesafe implementation. Java and
This being said, I think the question is moot, since they will never get the job using
--If I said something interesting it probably wasn't correct
Well, I'm not very a programmer, just did some programming a while back. So I'm not talking about PPOV(Programming Point Of View). As you and others have pointed out that most hospital use Windows OS, so think of .NET as current money now and J2EE as future money. While it make sense to think about what you can do in the future, it make much more sense for a small company to grab the money that is there now and hoping to get more later.
-=-=-=-=-=-=-=-=-=-=-=-=-=- If picture worth a thousand words, how many megapixels is it? -=-=-=-=-=-=-=-=-=-=-=-=-=-
And what will you do when Mainstream Support for VB6 is retired on March 31, 2005? Extended support lasts another 3 years, but Microsoft will only provide security fixes for free during that period. You must pay (or have a support contract) for all other support requests. And when Extended Support ends on March 31, 2008, you're really screwed.
Why would you want to stay with VB6 again?
The industry uses Windows in the office, so .NET is a logical choice. I happen to work for a healthcare services intermediary and I know that using Windows and .NET technologies is part of our ongoing strategy to developing tools to help both sides of the equation: providers of healthcare services and the payers of healthcare services. It's an easy choice. A small fraction of the healthcare market uses J2EE on a client level, and large hospital and physician networks want to use the technology standards that the vast majority speaks n: Microsoft.
We develop applications for health insurance (HIPAA compliant) at zeomega. These applications involve patients payors and providers alike so lots of PHI. we use FOSS platforms zope python ingres postgres mysql on linux runs like a champ , cuts down development time in half as python is easy to learn and program in. we used to do development on websphere before. not anymore. as far as .net goes ugghhh we dont want to wait for support on an 800 number helping some idiot thousands of miles away to fix his own bugs and dont even get me started on the security nightmare
the money is with the payors in this industry providers dont have deep pockets like payors. You will find longer sales cycles for providers than you do for payors and yes payors pay $$$
Heck, you could offer your customers a "turn-key" solution. Put together a cheap server running Linux with Tomcat for J2EE or Apache/Mono for .Net. Sell that for a fair price. Your customers just have to plug it in and turn it on. Your customers will have no extra license fees from MS to worry about. If you have any half decent developers on your team, they could write _standards compliant_ HTML and then you don't need to worry if your clients are hitting your web app with IE, Firefox or Safari. If your customers have a net connection, you can plug it into this Linux server you sell them and charge a small annual maintenance fee for support. If there is a problem, just VNC or SSH in and fix it.
If you go with a fat GUI client, then I personally would do it in Java with SWT (the toolkit used by Eclipse) for the GUI. SWT is very fast and lightweight. You can even get good SWT GUI designers to make coding easy. By going with Java for the GUI, you don't have to worry about what OS your customers use.
If you go with .Net, then you should use Mono and GTK# or QT# for the GUI. That won't lock you into just MS Windows for your customers. You would be able to deploy to Mac, Linux and Windows. I know my doctor uses an iBook. She carries it into the exam room all the time and manages all her patient records from it. So if you went with an MS-only solution, you would lose customers like her.
If you are developing an internal only solution, then use what you want. However, if you want to sell software (especially as a small company), you really should give your customers the most choice. If you went with a fat GUI client, you could sell a turn-key solution that ran Linux with Mono. Again, your customers will have no license fees to worry about, just your bill : )
I work as a senior programmer for a fortune 500. A few months back we went through a similar situation. However, we don't sell software, so everything we develop is for corporate use only. We had two camps. The J2EE camp and the .Net camp. We even hired three outside consulting companies to help make the choice. All three companies said that our web apps should be done in J2EE. However, politics won out and now we have different groups doing different things. Some are doing J2EE and some are doing ASP.Net C# and I get to be involved with both.
IMO, your senior manager should have no say in the technology used, just the features. The technology choice should be done by those who are going to _implement_ the technology.
That sounds like he has already be "won over" by some MS sales guy. .Net development is not going to be any faster then J2EE. .Net might even be a little slower at the start because you have
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
Clearly, there are a great many factors which could go into this decision, and really should. If we are looking purely at .NET (specifically C# and VB.NET) versus Java (J2EE), I think there are some things that we should consider.
First, what data base connectiveity is available with each of these platforms? Both .NET and Java have a myriad of tools for connecting with whatever data base flavor your project requires. (I know all the .NET haters are going to come out and say that Java is easier to connect to things, but I found that you can connect to almost anything from within .NET, with relative ease.) I see no real advantage for either choice here.
Second, what is the availability of prewritten chunks of code that you could use (even buy) to make your application development life cycle shorter? .NET and Java appear to have the same amount of commercially available controls and back end components. Again, there doesn't appear to be a winner here, with the possible exception of Java having more free components (due to the open source movement) because open sourcers hating M$. On the other hand M$ has written and tested several very helpful pieces of functionality which can be plugged into your .NET application (called Code Blocks).
Third, how hard is it to support and update your application (assuming it's an application that's not web based)? In the case of supporting, I think we also have a tie. In either case, you are going to have to see the problem, you are going to have to work on it. There is no magic bullet that let's you never have a problem in software (I don't care what language you write it in, nor what operating system you write it for). On the issue of updating your software, M$ has supplied a very powerful mechanism for programming your .NET software to update itself when it finds that something is out of date (you have it check the version number of the assembly in question, even done remotely and then download your updated assembly). Further, this functionality is encapsulated in a Code Block which is virtually "plug and play". Now, I admit my ignorance, but I don't know if Java has something similar. Please inform me so that we can have a complete disclosure before making a recommendation.
Fourth, how hard is it to secure? According to other posts, there have been some holes found in the sand box that sits around a Java application. I am sure that they will be found in the .NET CLR as well. I doubt that anything is perfectly secure. In terms of .NET, the security model is tied to assemblies, and each assembly you can lock down pretty tight in terms of who uses it, and how it is used. I would even say that it makes it a hassle for the programmer, since he has to go in and set up the permissions. I am not certain if Java has something similar to this, that is as powerful or configurable. Please let me know.
Fifth, where is this application going to be used? It seems, from the other posts that this application is most likely going to be run on windows machine, at least primarily. This gives .NET a potential advantage, since it would be running in its native architecture. Java used to be very slow on windows, I am not certain that is the case anymore. I know that .NET runs smoothly on windows.
Sixth, what is the future going to be like? All things being equal, it's clear that the future belongs to Longhorn and M$, at least in the case of large scale systems that require people with no computing ability to use them. I think this is something that /. Often overlooks, your average user cannot use anything more complicated than a microwave (and when I say that I mean, put something in, type the time, take something out, repeat ad naseum). M$ clearly has the majority when it comes to catering to less experienced users. Therefore, choosing .NET ov
I started reading the whole thread of replies, and I couldn't find a better comment than the one made by the first poster: "Java isn't slow, .NET is not insecure".
.NET, C or C++, try to think wether you have solid facts and a really large experience to support it, or just your idea of how things are, read elsewhere from someone you don't really know.
.NET for the way it's architectured, but the freedom it gives you in development it takes away in vendor lockin. I initially saw Mono with lots of suspicion, mostly regarding its legal status and possible future implications. Then I spent some time reading about it and ended up dismissing those fears.
A programmer worth its weight knows that each language has its niche, and for specific tasks there are enviroments that work best. Then there are those who believe the hype and form a concept of things without actually ever having a 1st hand impression. It's a bit like racism, applied to programming languages, and it has a common origin: ignorance. I hope this doesn't sound ecletic, but it probably could inspire flames, since people usually have a hard time admitting their ignorance. But the next time you feel like writing something about Java,
Also, the belief that a programmer can only be good in one language is ridiculous. Give a good programmer a month and he'll excel in whatever you throw at him in a given language. And what he doesn't know, he'll learn. Give him a project and a couple months and he'll know things inside out. Maybe he'll have a preferred language, but who's to say that won't change over time? Evolving oneself as a programmer sometimes involves changing paradigms.
That said, I consider myself mainly a C programmer, then converted to C++. Nowadays I use C/C++ very little, for very specific things or for my private projects (involving OpenGL & C++). I've worked extensively with Java, Perl, PHP, Prolog and bit in a dozen others. I'm in the process of learning everything possible about Mono/C#, and I'm enjoying it.
I don't really enjoy Java mainly because I find developing in it to be a real pain. When you have learned over 20 different languages, you value freedom of expression, and Java doesn't give you that - it locks you into a syntax that is archaic and not very flexible. I don't like the Sun Java team making choices for me, like not allowing operator overloading and not having propper syntactic support for modern OO concepts like properties. Maybe one day they'll understand the language syntax itself isn't important - just convenient - and will follow the road of Parrot or MSIDL (argh).
I like
I have recently gone through a process I consider similar to yours, and I don't envy you. It's a though choice. I recently spent almost two weeks studying the whole issue, experimenting with RAD systems for Java, Delphi, C++ and C#. In the end, I ended up adopting a solution based on LAMP2 (Linux, Apache2, PostgreSQL, Mono) - which should not be confused with LAMP (Linux, Apache, Mysql, PHP). Here's the reasons and thoughts:
- We find C# to be quite more expressive as a language. Mono is in a state good enough for us to use it, which satisfies our needs for platform independance.
- Java is not modern enough syntactically. It wasn't designed for some of the things it's used for nowadays, namedly GUIs, and that shows. Nowadays, having to write 'a.setLabel( a.getLabel() + "..." )' instead of 'a.label += "..."' looks stupid, and just shows what happens when people make decisions on your behalf based on their beliefs: on this I agree with Anders Hejlsberg.
- We prefer open source solutions whenever possible. We have many people with skills on PostgreSQL and its internals (we've had to extend it before).
- Apache is rock solid.
- Global input from the rest of the team.
There were, of course, lots of small decisions related t
"I don't mind God, it's his fan club I can't stand!" E8
We're WebObjects developers, for BlueCross (CareFirst), federal Government, and others. Java is the only way we'd ever recommend, and we'd definitely go with the premier web application envrionment.
But the real answers lies within; you should develop in the environment that is your strength. Does your 11 developers have experience in dot-net? Then via con dios.
- Ubique, Tom Termini www.bluedog.net - WebObjects / J2EE SOA / iPhone solutions for knowledge workers
I do emergency room software; and well, It depends....
.Net. .NET, hell COBOL.
Windows is most definitely the most deployed workstation in a hospital environment.
Go to the server room, and you will see the entire gambit from shiny new HP servers, down to small mainframes. This holds true for almost all hospitals over 30 beds.
So, if your deploying software to the workstation:
If your deploying server based software, do whatever you do best: Linux, Sun, VMS,
And forget about security, hospitals are about as secure (inside the FW) as an open cash box.
lick the cancle button (at least thats what our Chinese QA says)
If it was about coding speed, the question would be: "Which non-special character APL-family-language to use, J (http://www.jsoftware.com/) or Q (http://www.kx.com/)(formerly known as K)
Given that you have stated that this is a new market for your company and that there is no pre-existing knowledge or experience in this markte, I think you're jumping the gun by trying to select a platform. You can successfully implement the new system in any of the available platforms. The best advice I can offer is:
If you don't have requirements or a system design and you're worried about the implementation platform, you've already lost the race. Your system will end up being an ad hoc, organically grown, maintenance nightmare. Your best chance for success is to follow some sort of software development lifecycle instead of what appears to be the rush to select a platform and start coding. Factor in the learning curve for the selected platform to your project timeline, but jumping straight into coding before you know the requirements for the system and have a design to fulfill those requirements just leads to a waste of time, money, and resources that culminates in a failed project or worse, a badly hacked up product that results in bad customer relations.
That's my experience, but your mileage may vary....
...working at an University-hospital in Switzerland. Although almost every Desktop System present in the rooms for the nurses runs Windows, about 30% of our Physicians already use Mac OS X on their personal Systems, and more and more the Macintoshes appear in the Doctor's rooms.
(I do not need to mention the various server-systems like Solaris and Unixes)
Well, all I want to tell you is that in Switzerland, Microsoft is ALL BUT on the rising bar, and I personally think that you'll do better using J2EE, heading towards the "OS-independent" argument. Freedom of Choice is important.
regards
Silas
this sig is useless
then decide on t the platform and data model. Physician's offices are not the same as hospitals.
http://www.openehr.org and follow all the references.
Cheers,
Tim
If your deployment requires more than about 30-40 concurrent users, depending on complexity of app,an Win.net deployment would probably require multiple computer arrays with complex gateway framework. M$ is not known for building such large frameworks well. Instead they focus on making smaller deployments fast to write in and fast to run.
.net deployments that are having very serious performance problems even though they through tons of bucks at the hardware, they would all have been better off with J2EE. The performance is often related to both high and low concurrency.
On the other hand, with Java you can deploy on a nice juicy 10 processor *nix beast with terrabytes of stripped raid storage. By going J2EE on these systems you can get very high concurrency on one machine. You must have multiple boxes to acomplish this with win32. More computers == more complexity == more problems. With J2EE and Java RMI's (old but good) you can get very good multi-processor utilization.
Also, J2EE is better at deploying across multiple server farms such a linux array. By using multiple rmi's (one/linux box/processor) and an RMI gateway, you can get a very powerfull, stable and secure system. I get shivers thinking of how Microsoft is able to do this.
From my experience, I am seeing more and more
If your deployments are less than say 40 concurrent users, win.net is a possible solution but will be less stable and secure than J2EE on *nix. Above this 20 concurrent users, hands down I would go J2EE. At this level, the cost of extra processors & memory is relatively low cost in comparison to the application development & deployment costs.
Spend a bit more money on the hardware and you will sleep well having J2EE cranking away.
JsD
The decision depends on the background of your developers. With either language you can develop a highly reliable world-class application (folks do it every day). If your developers have experience in developing Pascal, C, or C++ applications then Java is a better platform choice. If your developers have backgrounds in RAD development languages such as Visual Basic, PowerBuilder, etc then .NET would likely be a better choice. The project ramp-up expenses (training-prototyping-design) will likely be very large, but you can minimize that by bringing in a consultant (or two) that is an expert (not just familar) in the platform technology that your group decides upon. Do not fear losing face by letting them lead because if you hire the best available in your market their resource value will be priceless.
We had no problem with .NET for our medical program. Development isn't what's going to get you. It's the fact that doctors don't know thing one about computers. Half of our bug reports were of things that the doctors didn't know how to use, not actual bugs.
You should memorize the hippa standards before you even start designing this thou. There are some very important things that will be required to be in your program that will get you into serious trouble if you don't have them already planned for.
Out side of that your probably already screwed if your asking the slashdot crowd for advice.
ProVation Medical is the leader in a new industry. They only have a couple "competitors" that can muster a single specialty while ProVation MD spans multiple specialties. They also have partnerships with several big players in the industry like Medtronic and Linvatec.
-- Scientist: You aren't going to leave me here, are you? Boagh! Thump...
What about HSQL, a database engine written in Java that has beaten some C++ engines and IBM's Cloudscape? Stated here
Now that's a fast Java app isn't it?
What did you do when he said that? Run some syntax analyzed minutes before he tries the compile or just destroy his hopes every day?
Are you sure?
Last I heard, Mono was an incomplete, slow and buggy implementation if small parts of .NET.
Please don't kid yourself that writing in .NET or Mono will allow you to produce secure, reliable, effective cross-platform software. You might be able to write something that runs on most modern versions of Windows, and providing you don't use to many of Microsoft's classes, it might run after a fashion under Linux.
It would be much more sensible to choose Java. It may appear to be a little slow in some cases, but it's mature, stable, reliable and secure. It comes with huge amounts of free classes for all kinds of purposes. If you're scared about it coming from just one vendor, fear not. There are Java implementations from many renowned companies, including IBM (currently a favourite of /.). There are free, Free and Open Source implementations.
In terms of portability, you don't have to choose between one complete implementation on one OS and a half-done one on one other (i.e. .NET on Windows and Mono on "Linux").
Contrary to what people will tell you here, the standard Sun JVM compiles to native machine code on the fly by default (you can turn it off with a simple switch), and gcc comes with a Java compiler which generates native binaries from Java source without requiring the JVM.
I think you'll find that if you choose Java, there will be fewer nasty surprises due to its maturity, and much more Open Source available to use in your project.
Stick Men
While on contract to large company over (8K employees)that has to be HIPIAA compliant AND SarbOx complaint, I saw 2 projects , one with j2ee and one with .net. The .net project is completed and the j2ee project is still going. Both projects were similar in targets and scope ( generating XML reports from 2 different financial systems and claims systems). Java is more difficult to do audit systems on, and is more complex when trying to design role based security. .Net is obviously nor portable, but has all that functionality built in to any number of languages. Since your target is physicians offices and hospitals (where the primary OS of choice is M$); I would work on the .Net version first and perhaps a j2ee version if you see any demand for it. C# and java are similar in syntax (more so than some of the other .net langs) and wouldn't be to difficult to get he core logic recoded. The difficult part (which would be the challenge anyway) would be to develop the security model.
...to ensure the customer keeps upgrading from one version of the underlying platforms to the next version. The quiet fact is that most notable commercial software is not written against any framework but rather a compiled language such as C++. Frameworks are designed purely to enable the relatively unsophisticated and ensure upgrade and mainetenance revenue. Frameworks always result in additional harware being required. >>
http://www.softwareobjectz.com
1. java is not slow, swing is. Poeple that dont know the difference should not make any IT decisions. Period. Swing is the reason why java gui apps run anywhere (no, this is not a myth). But you dont have to use it, there are alternatives. See "swt" and/or "gcj".
.NET Runtime has to be started also.
2. You dont need twice as much ram to boot java. the actual VMs share the loaded vm code for later on started java apps. Your
3. Stop fucking using Excel and start openoffice.org!
merry christmas.
First of all, John Dvorak, is that you? This looks like fresh copy for a business IT rag, bolded headers and all, but the main feature being clueless rambling that sounds knowledgeable and sophisticated. Now on to my main point:
.NET, the multi-language "feature" is really a non-feature, as most .NET languages expose the same API which is the set of classes in the .NET framework. .NET is like the ultimate "skinnable" programming environment; the language syntax tends to be different for each of .NET's guest languages but the underlying API, the base upon which the language is founded, is the same. There's some syntactic sugar here and there for people who are familiar with Visual Basic... but in actuality, .NET is no more multi-language than Java (which as noted elsewhere also plays host to code from diverse programming languages); and, it does not eliminate the far less trivial barrier to adoption that is its class API (which is different from both Java and Win32).
With few exceptions (COBOL, C++) I find I can pick up a new *language* in a matter of hours. Where the time really needs to be taken to learn, is in APIs. Oftentimes, as is the case in languages like Perl and Python, a new API is implied by learning the language, since you have to know the syntax the language uses for strings, regexps, and so forth. Smalltalk is a very tiny language with a very big API. Grokking the syntax can be done in minutes; finding out what all those little objects do, what methods they expose and how they may best be fit together to solve a problem requires lots of time, skill, and creativity.
With
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
If it's in the medical industry, that could mean peoples lives depend on your software. You're questions clearly indicate you aren't up to the task. I strongly suggest you withdraw your bid, or subcontract it to a company that is capable of creating such software and has the experience to know what the top two platforms are capable of without posting help messages on the message board of a news site. Ugh!
I'll give you a better alternative than either .NET or J2EE. Use Java without J2EE.
I have 25 years of large scale systems development. I have used both .NET and J2EE extensively. I would not base any commercial software on either. .NET is locked into Windows (where will you run your server software?), J2EE is not suitable for information systems development (use of a database is an afterthought). Both are too complex.
Use Java without the EE. Portability, scalability, runs on eveything, easy to develop/maintain! Reply for details.
There needs to be a special group at MIT that performs basic tests on a daily basis. They will report each evening on their findings. They will say one of four things:
.NET/C++/C/etc debates.
"Java is slow."
"Java is still slow."
"Java is no longer slow."
"Java is still not slow."
That's it, and there would be no more stupid Java vs.