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?"
are here. Read for yourself and draw your own conclusions
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
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.
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've never delt with the medical industry or HIPPA have you? Shared hosting with a remote web app!? The only upside would be that if they where ever audited, the auditor may just drop dead from shock.
I browse on +1 so AC's need not respond, I won't see it.
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...
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.
PHP is the answer to everything, the performance penalties of parsing each run and dynamic typing are actually bonuses for medical imaging and OS kernel work.
PHP is teh R0X0r!
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
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
So you're a MS-SQL guy then?
MySQL is a perfectly good database in terms of performance and core features. There are plenty of industrial strength applications which make use of it, and for most purposes, the "missing" features are of very little relevance.
PHP however, whilst a good choice for internet/intranet development is far from appropriate for realtime user interfaces, which is presumably what is required here. It's grown up to be a very powerful embedded language for web-based applications, but has little or no use beyond this remit. Even with the GTK bindings, you're still trying to get a sqaure peg into a round hole - it might be possible, but it won't be easy and the results won't be pretty.
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.
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
A .Net app could run just on the client if you are dealing with a small physicians office. .Net would be a much better choice than PHP, realistically no business is going to put an internal app on a shared host. If it is to be a webbased app running either J2EE or ASP.NET it could coexist with other apps on one server, it all depends upon users and load. For a healthcare provider which has to meet government requirements for privacy a platform with no company to back it up is fool hardy at best.
MS has pretty much bet the bank on .Net, so even if windows loses market share I can't see it going anywhere anytime soon.
.Net at work (not out of choice) and I must say that I've been pleasently surprised. Ethical grandstanding aside, VS.Net is a very good IDE and C# is a particularly nice language. IMHO, easier to use than Java.
I use
I still agree with your cocclusion though - depending on the current skill level of the deveopers of course, I think Java is the better option. Both platforms are pretty similar, but with Java you get (better, complete) portability.
Ben
.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
Yeah, like I want my medical records stored in a database that is touted for its supposed speed, not for meeting the requirements of ACID transactions.
MySQL is a good database for small web apps. But it can't compare with Oracle or even lowly MS-SQL. It still lacks and triggers, I'd imagine that a lot of logging needs to be done for a health care app. A trigger in the database would seem to be important for this case. Secondly I'm gonna catch flak for this MS-SQL scales better than MySQL. MySQL will be there one day but its not quite there.
he last thing you need is Microsoft changing their APIs yet again to some god-forsaken, bloated, filth.
Whats to keep Sun from doing the same thing?
The Doormat
If you're not outraged, then you're not paying attention.
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'd second that. I've been using Python exclusively for the past year or more in commercial projects, and quite a bit on and off prior to that personally.
.NET or Java runtimes. If deployment is a major issue, then it's simple enough to create and ship a single executable.
Combined with a good GUI toolkit (wxWidgets or for certain applications GTK+ and the wonderful Glade) and with a good database back-end (MySQL on the server and possibly SQLite for local data) you really can do pretty much anything very quickly and effectively. There are even some great free development tools (like DrPython) which are a joy to use.
You get to target GNU/Linux, Windows and Mac OSX with essentially the same source, and installing the Python and related runtimes is no more hassle than installing the
I've used it for developing everything from Point-of-Sale systems to document imaging and retrieval to accounting systems. There are quick applications for feeding data from legacy systems into new systems, batch processing of large amounts of data, as well as some pretty major fully bespoke applications. It really has proven to be a one toolset fits all solution for me.
Looked at and used Perl, Ruby and Lua for a while before decideding on Python. It just had that little something extra for me, and I've absolutely no regrets, but all four would bring you most of the same benefits, though you may find that Lua is lacking somewhat in add-on libraries at the moment.
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.
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.
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
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.
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
At least I have the courage to publicly stand by my point of view, as opposed to yourself... too gutless to express an opinion using your own name. Artard!
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...
J2EE runs on J2SE, and there are plenty of facilities available for:
- Running web-based clients to business objects
- Running flash-based clients to business objects
- Running Swing/SWT fat/rich clients to business objects
However, unless you use Flash, UI work is not as easy for the developer as it is in Visual Studio (or Delphi, for that matter).
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 have just started working with REALbasic. It is a fantastic product, and making applications with it is a breeze, especially across platforms. User community is very supportive, and the folks who started REALbasic often weigh in for help. Might be a little too small at this point for you to convince the higher ups though. REAL software website
I would think a flash client for a medical app is rediculous.
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.
Hmmm... let me think about this comment.... BuHAHAHAHAHA!!!! Microsoft secure AHHHAHAHAHA!!!
/. advice so don't take it too seriously ;) ), look at your target market, pick the best tool for the job, always have a backup plan if that tool doesn't work.
But seriously, I respect the fact you made some of these comments. But I think some of the reasoning is flawed. Windows is simply not a secure platform from both a quality and archectecture standpoint. I know this from experience (heavy amounts of development for many, many different operating systems... not just Windows/Linux)
I do agree with your comment on researching the target market and that is often what is forgotten when using the latest wiz bang technology. Pick the best tool for the job. Just because it's today's buzzword does not mean it's the best tool.
I simply do not think that Windows can hold up to HIPAA. Would you trust Windows to cover your legal butt? I am not saying this as a Linux/BSD/Solaris/MacOS/VXWorks/PSOS/etc zealot but simply from experience. Security wise, Windows still has a ways to go (i.e. allowing arbitrary code execution from a web page, email, etc). When it gets there then I will trumpet Windows as a secure OS.
My advice (and it's
Healthcare is probably the same, if not even more restricted. Software developed for US healthcare is pretty anal. As I understand it, every user-driven event has to be audited and signed with a key.
Is this going to be a ginormous database, or a relatively small one (local office keeping track of appointments)?
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
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.
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
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.
Unrelated, but the project described in the article is going to fail. Here's why.
HIPAA is a real bitch. You're going to need an attorney practically on staff to work with the developers in planning this product.
How are you going to input existing records into the EMR suite? OCR? Hire a typist (consult your attorney again)?
Transmitting personally identifiable health information over the internet? Great idea! HIPAA again.
Doctors will pay for this...why? What, with doctors having to pay tons in malpractice insurance these days, they're really sticklers for cash. Really, though, doctors are really cheap.
Integrating claims? Hope you are up to speed on HL7 and Z-Modem. HL7-XML is still in working group, and don't expect a release for at least another 5 years. Also, good luck with Medicare/Medicaid claims, really, if you can do it, let me know how.
Going with the ASP model - well that's wonderful. What happens when the office's DSL goes down? Looks like they can't serve patients anymore. Oh well.
Private practice and hospitals? Impressive. I sure hope you're going to integrate medical instrument interfaces to this product, or why would a hospital use it?
Any EMR worth its weight is going to have to integrate both ICD-9-CM and CPT. If you don't know what these mean, give up now. ICD-9-CM is free, but CPT is commercial. Last time I checked, around $200 per license. Planning on distributing CPT codes within the product? Good luck with that one, too. Unless, of course, you want physicians' offices to manually input their CPT codes into the system ( all 5,000+ of them ).
Just my short list of why you're not going to make money selling software to the medical industry.
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.)
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
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
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.
.NET is already being phased out. When longhorn comes out it's all new stuff. Of course .NET will be supported but it will have no buzz and all the developers will be encouraged to abandon it.
evil is as evil does
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/
You do realize .Net is the replacement for Pe executables for longhorn don't you? the only thing being phased out is System.Windows.Forms, and its being replaced with avalon. However System.Windows.Forms will continue to be supported for quite some time.
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
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 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
Yes yes yes. It was a typo. Christ slashdot has a excess of spelling and semantic police.
I browse on +1 so AC's need not respond, I won't see it.
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.
ARGH! It was a typo! Anyway, everything else you said is dead-on. I've done work with several large healtcare firms, as well as several medical software vendors. Compliance with HIPAA is insane. No one is ever sure what exactly has to be done, because it is so vague, but is scares the hell out of them so they get all freaked over everything. If the software package WILL interface with medical equipment, don't forget the fun of FDA certification! I've seen it done, and it's insanely complex.
I browse on +1 so AC's need not respond, I won't see it.
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.
A .Net app could run just on the client if you are dealing with a small physicians office. .Net would be a much better choice than PHP, realistically no business is going to put an internal app on a shared host.
PHP can run on a local host also. Do you mean non-HTML-browser apps?
Table-ized A.I.
PHP is a toy for amateur web developers who do not care about security or scalability, not a tool for serious work.
Can't you provide something more specific before bashing a tool/language?
Table-ized A.I.
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
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.
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.
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
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.
Some are effectively just desktop apps, but some are quite big.
Python has never really been about speed, and for the client side code it's not important anyway, most of the time the app is just waiting for user input. A lot of the number crunching is done by the database server so all the app is doing is issuing a query, albeit often quite a complex one, and waiting for the results.
There are obviously major productivity benefits to programming in Python (and scripting languages in general) but you trade performance for these. There have been a couple of times when I've approached a large new project and half expected to end up recoding sections in C++, but for all the projects so far, the pure Python versions have performed as well if not better than the client had expected anyway, even on older hardware. The core libraries and many of the popular extensions are written in C++ these days, and those that aren't and become popular tend to be re-written before long as well.
I've personally found that Python scales as well as Java ever did, but then I've not really written anything in Java during the past two years, and performance etc. may have improved to the extent that the difference is now significant.
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.
php5 seems just to be a copy of java.. pffft i've got no time for it. real men code stuff in perl :p
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.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Suddenly the "Blue screen of Death" takes on a whole new meaning....
Cat: The other white meat
MySQL+InnoDB does ACID.
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.
It doesn't matter if you think that Windows can hold up to HIPPAA. It matters if HOSPOC IT staff, the FDA, and other federal regulators think that it can hold up.
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.)
Actually, very little has to be done to maintain HIPAA compliance. Treat all information as confidential and owned by the creator, unless released to another party for review. Secure ALL communications of medical records, and make sure you understand the difference between record custodians and record owners.
Very few insurance companies will even consider HL7 data, everyone has moved to some form of ANSI 837 transaction. Look at options like Availity (or something better, let me know if you can find something without that crappy web-based post/download claim thing) and bill Medicare/Medicaid directly.
Doctors will not pay for this, but they WILL pay a nominal fee for monthly service, especially if bundled with Internet access, or may instead agree to a (small) percentage of paid claims. ICD-9-CM and CPT-4 are both free, provided you look in the right place. Most insurance companies will post a fee schedule, which is free to distribute, containing CPT codes and their associated modifiers. Try Medicare for a good start.
Finally, for the original topic, it doesn't matter what language you use, but you'd better have a VERY flexible design (as everything will change about every 5 years), and be able to provide equipment legally, cheaply, and reliably. You didn't think those doctors were going to buy their own computers, did you? Believe me, Windows licenses are not something you want to deal with if you have hundreds of clients. Also, forget hospitals. Hospitals are owned by large corporations, who either contract with a large corporation for development, or have their own in-house development, they don't buy shrink-wrapped software.
In other words, if you're doing this to make money off your practice management system, don't. There is no money, unless you get something else out of it, like exclusive contracts for other services.
--That's the point of being root, you can do anything you want, even if it's stupid.
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.
Great, so memory management in future versions of Windows will be WORSE? You'd be surprised how adding a simple string to a string can eat memory (I've reached 400MB for a test case constructing about a 300KB string, it's actually faster by several orders of magnitude to write to disk than append to a string), and how long it takes for it to be GC'd.
--That's the point of being root, you can do anything you want, even if it's stupid.
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
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.
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
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
Development lifecycles you say?
.NET been around?
Java has been around for almost 10 years+. Refresh my memory with some of those CS courses you took (that emphasized, in your opinion, "development lifecycles"), how long has C# or
I'm not goint to lower this thread into a Java vs. C# debate.
RAM is cheap. Learn Java and make some cash, so you can afford some more RAM to run Java apps, so you'll stop "bashing."
You sound like an angry MS nut that just realized C# isn't going as Microsoft planned, and you're resorting to those protective instincts that are inherent in any MS programmer - "bash and use lots of buzzwords."
There's pissing contests all over. OSS is just another one.
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 !
I agree but
.NET is way more portable than java..... I can compile a dll on my windows b0x and run it straight on my openBSD b0x, my iPaq or even a cellphone. try that with java and the 'java enabled' machines which actually run a crippled vm.
.NET has provided!
Both platforms are pretty similar, but with Java you get (better, complete) portability.
in my experience
And ofcourse I like the delegates and pointers that
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.
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!
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.
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
You sir, are full of shit. The .NET Compact Framework VMs are just as crippled as a J2ME VM, and will not run a Desktop targeted DLL or EXE. There are no differences between Java and .NET as far as Desktop vs PDA/phone devices, other than Java being available for far more platforms than .NET, and having been around longer there are more versions of Java, hence backwards compatibility problems.
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.
Also you shouldn't leave out that .NET is immature, and has much higher system requirements than Java. Plus, when you develop an application for Java, at the very least it works across Sun's VMs, if not all vendors' Java VMs (as is often the case). .NET? No, sorry, you wanted a user interface. Can't forget how willing MS has been to port the .NET system to things that aren't Windows, as well.
.NET created all of them over again, and added a couple more: .NET software
I don't like Java all that much, but most of my objections have been fixed over the years.
-Small installed base with the
-.NET CLR is very large to download
-Very large memory requirements
-Noticable slower than native code
-Limited cross-platform support
-Non-ported components
-Windows OS has the only finished implementation
-Lack of need for system to exist
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
- Microsoft essentially obsoleted our entire company's code base when they introduced .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 (or Java) seems crazy.
VB6 still works fine, by the way. You were not forced to do a rewrite. If your code base is in VB6, and your developers know VB6, then the decision to go to
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'm with stupid (But maybe with PostgreSQL as the DB.)
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.
Let's just screw the "microsoft is a patent holding monger that will some day come back and screw us" discussion, and think about things in perspective. Microsoft holds patents and Sun holds patents, I really do not see the difference in the two. I know that microsoft has the bad reputation but that is not the question at hand. Who's to say that sun could not do the same thing that microsoft could. The question is not patents and lawsuits, this is a question of which development platform would be better. Which really boils down to which is the easiest platform for you to develop with and not which platform is better for the customer. A matter of taste, so there is no real answer.
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 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?
Oh please.... it's an ugly hack bolted onto the database, and the stitches are showing. MySQL is the Access of Linux.
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
"Microsoft essentially obsoleted our entire company's code base when they introduced .Net, forcing a rewrite that will cost millions"
Yeah, let's go with Java because IBM supports it!! Someone who supports Java would never do anything like that *cough*banks*OS2*cough*
"one patent infringement lawsuit from MS and it is gome (sic)"
Yeah, like when Sun sued Microsoft over Java and now MIcrosoft's Java is gone. Just goes to show anyone will sue anyone, there is no protection because you are not going with Microsoft.
Why am I bother to respond, I can tell by your posting your probably a high school coder anyway.
I don't disagree with Java as a choice, in fact I agree with it, but for reasons that make sense, not made up FUD. Stop whining "me too".
slashdot troll = you make a compelling argument I do not like the implications of.
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.
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.
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? -=-=-=-=-=-=-=-=-=-=-=-=-=-
... which is a redirect to http://www.mono-project.com/about/index.html.
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
Yeah, let's go with Java because IBM supports it!! Someone who supports Java would never do anything like that *cough*banks*OS2*cough*
The difference is that Microsoft has formally announced retirement of VB6 support. While with OS/2 even now you can get support from IBM.
http://www-306.ibm.com/software/os/warp/support
Just goes to show anyone will sue anyone, there is no protection because you are not going with Microsoft.
The difference is that Java runtimes and sdks for platforms other than Solaris are produced by Sun itself. Is Sun going to sue itself for violating it's own patents? I don't think so.
"microsoft is a patent holding monger that will some day come back and screw us" discussion
.Net on other platforms you must go and use an unsanctioned, unlicensed reverse-engineered platform that is not supported by any way shape or form by Microsoft, and which has been threatened in public by the CEO of Microsoft with patent infringement claims. Sun is not about to sue Sun for patent infringement - while MS has openly discussed doing the same with Mono.
The issue here is Mono vs. Java and cross platform support. Sun produces JDKs for many platforms, Microsoft one. In order to develop for
Right now Mono serves Microsoft's needs in a number of ways, most especially in the area of providing a 'see we are not a monopoly' example. Should those needs change so that Mono is undesirable Microsoft could pull the plug on Mono in a femtosecond.
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 $$$
You obviously have no idea how to develop code under .NET. We run a heavily loaded ecommerce site with 8 servers / 2 cpus each with absolutely no prob. Btw, this solution has replaced a legacy Java app that was running on 16 servers / 2 cpus each. .NET rocks.
That is a ridiculous example and you know it. If you are doing a re-write of a legacy application and can't come up with AT LEAST a five-fold improvement in performance you are totally incompetant.
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)
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.
I see you were brave enough to actually post with anonymous coward. Thats nice.
No, PHP would crumble when even 100 of the 4000 users simultaenously click on a scheduling form that produces OVER 500 queries to the database.
I've worked in enterprise healthcare for many years. I've seen quad Xeon boxes running other EMR suites that can't handle 30 users at once.
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?
Thats funny. Really. Considering the mutlitudes of clustered machines that are necessary to host that kind of volume does not speak well its scaling ability. It speaks well of a company willing to throw tons of money at something in hardware to make it work.
How many boxes does Hotmail use? Last I heard, it was in excess of 600! Thats not efficient.
When you actually have some gall to post as a real user, AND some credentials to back up your weak ass claims, talk. Until then, enjoy your mom's free room and board.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
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)
As others have mentioned, you are not FORCED to rewrite your VB6 app to VB.Net. It still works and compiles.
.Net framework (and has hooks for Active-X if needed). You might as well complain about the difficulties between porting back and forth between Carbon and Cocoa on the Mac.
.Net is nice for windows coding, but for anything cross-platform Java is nicer. Java is also more mature and rock solid.
VB.Net is a whole other kettle of fish. It wasn't meant to be a quick import. The coding is different (object oriented), and uses different technologies. You're essentially complaining that a language and IDE based on COM and Active-X doesn't port well to a language based on the
However, I agree with your Java arguments.
Java's definately the way to go. But complaining about VB6 -> VB.Net is kind of pointless.
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.
Thew VEIWS creation is plenty buggy. I wouldn't install 5.0 just yet
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...
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
What the HELL are you talking about? C# is an OPEN standard, with 70%+ open to public
.NET Framework.
I call bullshit. C# is a standard, but that doesn't mean it's useful in that form. Microsoft calls their product Visual C# for good reason - it is the C# language PLUS project templates, designers, property pages, code wizards, an object model, and other features of the development environment. The library for Visual C# programming is the
NONE of this is part of a standard except C# and the System library, and it is ALL part of what people use when they write C# applications.
As others have mentioned, you are not FORCED to rewrite your VB6 app to VB.Net. It still works and compiles.
As others have said, mainstream support for VB6 ends March 2005. There is no way my clients will buy applications written in an unsupported language.
As a result, yes we are forced to rewrite. Otherwise we are out of business.
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
There's a *huge* difference.
Sun has worked for the last decade trying to ensure above anything else that Java works on as many platforms as possible.
Microsoft have worked for their entire life as a business to ensure that software only runs on their system.
The track record of these companies should be all the argument that people need.
That law suit was fought to preserve the integrity of the Java language, not to kill it on Win32.
A MS suit against Mono kills .NET on Linux.
The Sun suit against MS preserved the ability to code portable Java on Win32
Spot the difference?
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.
Nope, just a play in words in the direction you wish it to be read.
Microsoft could easily say the same thing if they went after Mono.
Sun sued Microsoft over Java because it took market share (mindshare) away from Sun, and they had a contract that allowed them to sue. Any other belief is fantasy. If Microsoft had not been in a special treated monopoly position, the courts would have thrown the suit out even with the contract.
slashdot troll = you make a compelling argument I do not like the implications of.
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!
I would question the architecture of a system that requires push updates to the client. There are other reliable ways to achieve the desired results. This is the reason PointCast got marginalized.
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.
Bullshit. Sun was happy for MS to ship Java, they weren't happy for MS to ship a incompatible product and call it "java". In no way did it benefit Sun to have MS stop supporting Java, except insofar as it kept the language pure. Sun would have been much better off if MS HAD supported pure Java (shipping Java in Visual Studio was a huge boost)