Let me say first (again, actually) that I’m totally clueless when it comes to web programming: I’ve been working on desktop applications (and one device driver) for the last few years. Now our client is considering moving our application to the web, and never having done this I’m not sure what the best approach is.

From what I understand,.net is that it supposed to be good for this kind of thing. I haven’t gotten to deep into it, but it seems to offer a great deal of power using languages similar to what I already know. The only drawback is that you have to use Windows servers, and I’m not sure if this would be a good thing being that over 15,000 users currently use the desktop version of this application; we expect about 80% of these would log in and use a web-based version in single four-hour timeframe.

We have other web stuff using Sun servers and Portal (which I know nothing about), and this seems to be the preferred method of handling large numbers of users. Sun, as I understand it, makes better servers than M$, but I know very little about Portal or PHP and would have (I believe) a steeper learning curve porting this application over to using them, not to mention everyone here seems to despise working with Portal.

One other factor is that whatever solution I choose, the data will be stored in an Oracle database.

My questions are:
1. How closely can I make a web version look to my desktop version with .net (assuming that it is a straight-forward windows app)?
2. Can a Windows server (or servers) handle the number of users we are talking about (without astronomical expense)?
3. How closely can I make a web version look to my desktop version using Portal and PHP?

I know this isn’t my first post on the topic, but any help would be greatly appreciated. Our client just came up with a big wad of cash and I need to devise a plane to help him spend it.

look into Rich Internet Applications with FlashMX (video overview.)

How closely can I make a web version look to my desktop version with .net

The first thing that occurs to me is that if you did go this route, it's likely to use IE-specific stuff, which always pisses me off, as I don't frequent platforms that have IE available. Now, obviously, it's up to you as to whether you want a browser platform or an IE-only platform, but it seems to me that it would be more beneficial to provide services more openly. Otherwise, if you're restricting it to IE, then why bother changing it from a standalone app?

Can a Windows server (or servers) handle the number of users we are talking about (without astronomical expense)?

Obviously, it depends on how hard these users are going to be on the servers. What I can tell you, though, is that it's hard to find a Windows machine that has more than four processors, and I'm pretty sure that nothing beyond eight exists at all. You can get Sun machines (for example) with up to 106 processors. Obviously, the cost of that would be astronomical, but the point is that the server could grow with the app load. If you go with Windows, you'll have to make sure that it operates in parallel with other servers doing the same thing. This might be trivial or it might be nearly impossible. I don't know, but it's something to keep in mind.

Thanks for your input.

The first thing that occurs to me is that if you did go this route, it's likely to use IE-specific stuff

Would this be avoidable with good coding, or is it pretty much determined that using .net restricts the user to IE? Either way it's probably not important to the client, as all of the users are already required to be running Win2K (or XP shortly). I do hate writing restrictive programs though.

Obviously, it depends on how hard these users are going to be on the servers.

Essentially all the users will do is log on, select a bunch of data from a database, and print out some forms. The only issue is that it is not inconceivable for the vast majority of them to all do it within the same four-hour time window.

Scalability is nice, but I’m not sure it’s going to get much bigger than the numbers are right now. We’ll scale up initially, but I don’t see us servicing more than 20,000 people. I should also mention that we’d have at least six servers, as the information the users input will eventually go to six different sites. Since this makes for a logical breakdown into six different groups (which are very clearly delineated), it makes sense for each site to have it’s own server (or servers). Of course, I could totally be talking out of my butt on all this; I’m just regurgitating what our current web (Portal) developers are telling me.

Would this be avoidable with good coding, or is it pretty much determined that using .net restricts the user to IE?

I don't know a lot about .net, first off, but this particular response was in relation to the ``How closely can I make a web version look to my desktop version'' part. I've seen a number of web applications that use DirectX or other nonsense to make a web page look exactly like a standalone app by using the full widget set of Windows. That sort of thing is going to be IE-specific, and not .net specific at all. .net should be able to transmit fully w3.org compliant stuff to the browser.

So, yes, it would be avoidable with good coding, but the more cross-platform you make the app, the less like your desktop app it's going to look.

You could write it as a Java app, conceivably, and have a full widget set of some nature and still be fairly cross-platform.

Essentially all the users will do is log on, select a bunch of data from a database, and print out some forms.

If all you're really doing is gathering data, then parallelism shouldn't be hard at all. The Intel platform is probably your cheapest bet there. It'd be really cheap if you had someone who could administer a Linux, FreeBSD, OpenBSD, or NetBSD machine, as you wouldn't have to worry about paying Microsoft for their OS and trying to figure out their apparently intentionally obfuscated licensing scheme. Of course, you then have to figure out how to send different people to different servers.

My point about that in general is that if you are testing out a 4CPU Intel machine and it doesn't do the job, then it's hard to get any bigger. If you were testing a 4CPU Sun machine and it didn't do the job, it's easy to buy a bigger one that wouldn't require any difference in your app.

over 15,000 users currently use the desktop version of this application; we expect about 80% of these would log in and use a web-based version in single four-hour timeframe.

Looks to me like you need a UNIX based solution, based upon the number of users over time.

We have other web stuff using Sun servers

Aha.. so you have some Sun experiance already - If the client has the cash, run Solaris (rock solid)

One other factor is that whatever solution I choose, the data will be stored in an Oracle database.

Oracle and Solaris play very well together.

My questions are:
1. How closely can I make a web version look to my desktop version with .net (assuming that it is a straight-forward windows app)?

You should probably be asking "how can I reproduce the functionality of the desktop app" rather than trying to make the look-and-feel the same. Web development is a different beast than desktop development, and not everything that works well on a desktop app will transfer to the web easily.

You haven't really spoken to the complexity of the application. Is it just a reporting tool, or does it do much more than just getting data from the database and displaying it? If it's just a reporting tool, or data query tool, it could easily be done with many different web development tools on Solaris (sorry, I don't consider win32 a viable server platform)

PHP with Apache/SunONE - easy to write in, not very modular

Java with Weblogic or JBoss - write your apps in beans, then they are modular, and Weblogic or JBoss will provide you with load balancing, etc (they are containers). There are a lot of tools to use for Java development (NetBeans, Rational). Oracle provides you with some superb JDBC drivers that can be optimized for your load.

I'm a little biased towards Java development because I've seen it work for me in enterprise apps before. I've used PHP some (I wrote a web-based e-mail package in it) and it just doesn't strike me as a viable enterprise level platform. Java was designed that way, and you can get a lot of support from other companies for Java that you can't get for PHP.

The first thing that occurs to me is that if you did go this route, it's likely to use IE-specific stuff

Would this be avoidable with good coding, or is it pretty much determined that using .net restricts the user to IE?

As I think has already been said here, using .net doesn't mean you _have_ to restrict clients to IE at all. You can benefit from .net's features on the server and make your application faster (and easier) to develop while at the client end they still see the same html (or whatever).

Off the top of my head, I think answers to these questions will help make your options clearer:
- What type of data handling capabilities do you need at the client end?
- What is the nature of the data?
- Do you need to update the database with data sent back from the client?

Excellent post, you're confirming a lot of my suspicions. I've been leaning the Solaris route but have been cautious, as this is a totally new world for me (though we do have at least one person here who knows it really well).

You should probably be asking "how can I reproduce the functionality of the desktop app" rather than trying to make the look-and-feel the same.

True, and I know that deep down. It’s just that I recently overhauled the program to look and feel more user friendly and our users have been VERY responsive (you can’t imagine the good-guy emails I’ve been getting simply for adding coherent menus and cute icons). I suppose I just like the attention.

You haven't really spoken to the complexity of the application. Is it just a reporting tool, or does it do much more than just getting data from the database and displaying it?

It’s slightly more than a reporting tool. I can’t go into specifics (security is a big thing here), but basically it allows the user to input data (simple, single line records), pull information from those records, and print out a dozen or so reports. One of these reports is used to update information on a different system that currently is not on the web. If my application gets moved to the web, one of its new tasks will be to update this other system directly instead of using a paper trail to do it. Eventually this second application will return data to my application so the user can view the results of the transaction. As I said before, right now the only connection between my desktop app and the second app is a report that is printed out.

My quick and dirty opinion:

- Dotnet is new and unproven. Microsoft has a poor track record for the security of their web server software. I would be wary of doing it in Dotnet for this reason. This doesn't mean you can't make a microsoft web server secure, it just means it's harder to do and you've got to have the tools and the time to watch those servers like a hawk.

- It would be easy to do in Dotnet. Setting up the web servers and coding the application would be relatively painless. And yes, one advantage is that you could code it in such a way so that the web version looked and felt exactly the same as the standalone version if you wanted it to.

- If you're used to doing Microsoft development already, then there's no reason you can't do it with existing (pre-dotnet) Microsoft server technology. In fact, if we were doing something similar, this is the route we'd probably take because we know how to do it this way already.

- You could also do exactly the same thing in just about any other web server system other than Microsoft's. From your description, it's pretty simple: Getting data out of a database and displaying it in HTML is the basic bread and butter of any web server system.

- No matter which system you use, you'll need to do load testing before going live. Even after the load testing, there will be some growing pain when you do go live. Like you said, that many users in a four-hour space is a lot. Whoever sells you the server license, regardless of the vendor, is going to blow smoke up your yinyang regarding TPM numbers. You might want to ensure ahead of time that the system is scaleable even if you don't anticipate a need for growth.

Okay, if it's primarily a database front-end it would be very easy to use any number of web programming languages to duplicate the functionality of your app.

One of these reports is used to update information on a different system that currently is not on the web. If my application gets moved to the web, one of its new tasks will be to update this other system directly instead of using a paper trail to do it.

Something you may want to look into is some kind of messaging queue. We use JMS (Java Message Service) to ship data back and fourth between apps and it is invaluable. This ensures that you have a layer of abstraction from your apps, and could replace the apps easily (or integrate them easily) in the future. The data is in XML, so any application regardless of what it is written in can access it.

While there are servers with dozens of processors theoretically capable of running M$ Datacenter Server (or whatever the name of that incarnation of NT) - see, for example, this monster from Unisys - it is far more difficult to find real-world example of 10000+ users transactional app actually deployed on Windows than on some Unix, OS/400, zOS, and they tend to be more expensive, Evil Empire FUD notwithstanding.

To make your Web app behave like desktop version (field-level validation, quick selection popups, dynamic menus, fast scrolling of large data sets...) neither portals nor .NET per se will help. You will have to use something client-side, making your thin client gain some weight. You can force-feed it JavaScript (perhaps communicating with back-end using XML a'la SAP NetWeaver), Java applets (which are just easily deployed desktop apps in different guise), something from MacroMedia... In general, it will be difficult. Take a look at goodies in Apache Jakarta project, in particular Struts. They are not magic bullet, but they halp. The price is quite enormour amount of semi-manual coding in Java, JavaScript, HTML and XML.

Alternatively, you can try to redesign your app so that it is reasonably comfortable despite being 'typical WEB' - that is, mostly screen-level validations, somewhat slower inter-screen transitions etc. The upside is that you will make the app with 10% of time and effort, if you use some of the rapid application development tools. My company uses Panther in conjuction with either BEA Tuxedo or IBM WebSphere (or MS COM/DCOM/COM+ for smaller deployments). Note that you can still mix-and-match JavaScript, Java or ActiveX components.

Good luck!

look into Rich Internet Applications with FlashMX

or not.

or not.

???

I'm not discounting anything, yet. I'm still trying to absorb all of this!

I'll throw in one more vote for java on some sort of unix. It will scale better than the other options and can be done significantly cheaper if that is a concern (jboss + apache + linux = free software on cheap intel hardware). If you go that route definitely checkout Struts as someone else mentioned or Turbine (thir DB layer Torque is awsome to work with).

PHP isn't a bad option either if you need quick development, but in my opinion you suffer latter when you need to update the system as it is harder to write nice structured PHP code.

Personally I woudn't touch .NET or any MS product for a server platform, but I know I am extremely biased and others have already covered most of the reasons why (security, MS license fees, good hardware availablility, etc).

-Mike

Does the new version of the application actually need to be a web application, or does it just need to be accessible over the Internet ?

You are going to have to invest an awful lot of time into making a web site look like your existing Windows application. If you have to also make it work on both major browsers, even if you can limit yourself to just the latest versions of both then you can easily add another 50% of effort to make it look/behave the same on both IE and Netscape.

If you in fact only need to make the application work over the Internet, then why not just use web services on the webserver and have your Windows application call the web services to get it's data.

This of course doesn't gain you any cross platform portability as a web approach in theory would give you. However in practice if you are trying to produce a rich client feel with a website you will have fun even dealing with the differences between IE on the PC and IE on the Mac, let alone the differences between IE and Netscape.

If you re-wrote your Windows app using .NET then all the web services stuff comes for free. Even if you stick with the exist app it should be too bad. Assuming your existing app is using ADO you can insert an extra layer between the bit that consumes ADO recordsets and the actually data access. You can then have you new web services layer build ADO recordsets from your web services call and pass them up to the layer above. Then you would need less changes in your existing code.

I guess if you re-wrote the app in Java you would get some platform portability and you could still take the web services appraoch.

My point about that in general is that if you are testing out a 4CPU Intel machine and it doesn't do the job, then it's hard to get any bigger. If you were testing a 4CPU Sun machine and it didn't do the job, it's easy to buy a bigger one that wouldn't require any difference in your app.

In my experience it is almost always more cost effective to design your app from the outset to work in a web farm enviroment and then when your 4 proc box runs out of steam start adding more 4 proc servers. The cost of flash hardware doesn't tend to scale linearly.

It does mean you need to invest in a hardware load balancing switch to do it properly though.

Does the new version of the application actually need to be a web application, or does it just need to be accessible over the Internet?

Actually we could just use web services, but recently we've been burned by a bug getting out and the client not wanting to release a patch to fix it (too many users to send a patch out to even though the bug is severe - you really don't want to get me started on this situation though). This has bolstered the idea of being able to roll out a web version because it would be easier to fix when problems are encountered.

You are going to have to invest an awful lot of time into making a web site look like your existing Windows application.

I was under the mistaken idea that .Net would give us this ability easily. I see now that this was an incorrect assumption. So I believe that look and feel is going to have to take a back seat to functionality (imagine that!), but as long as I can come up with something that isn't too confusing to the users there shouldn't be a problem. We'll just have to make sure there are some user-benefits to the web version to make sure they all move over.

Agreed, I've seen some prices for 6, 8 and 32 way WinTel boxes, and they can be very pricy.

To be fair, I don't believe that 8-32 procs is appropriate for a web application anyway - DB perhaps, but not a web app.

Andy is right, in that the application needs to be load-balancable for High Availability if nothing else.

Paul.

Thanks everyone for your help, I think I’ve been able to refine my questions a bit so I’ll need just a little more advice. This situation is this now: the client has decided to fund this project, and I’m in charge of it. We’re going to decide our strategy in a meeting tomorrow morning, which means throwing in with M$ or Sun, which is what I’ve boiled the options down to. In fact, unless someone can convince me otherwise (and I don’t think anyone here is likely to try) I’ll be recommending using Solaris for the simple reason that we’re already maintaining a few Solaris servers.

This, of course, rules out .net, but there are still decisions to be made. Now keep in mind I’m learning here, so I may get some of the terms wrong, but the next thing I apparently have to decide on is an application server. For our current web project the web developers are using Oracle 9i Application Server, but they question it’s stability. However, they can’t offer me any suggestions of anything else to use, so I suppose I have to ask: what is the best, most stable application server I can run on Solaris? Keep in mind that there will be thousands of users and security is of utmost importance. It also has to be PKI enabled, or so I’m told.

As far as actual development, it seems that using JSPs is the way to go based on what I’ve read here, are there any other suggestions? If we go with Oracle 9i, I’m being told that JDeveloper is what I’d probably want to use to create them. BTW, as I said before, the backend will most definitely be Oracle.

If it sounds like I’m in over my head, you better believe it’s true! I feel like I’m walking around blind and half deaf. The worst thing is that the “web guys” around here don’t seem to know much more than I do. Fortunately with the new funding I’ll be able to hire another person for my team who’ll presumably actually know about this stuff, but I have to know which technology we’re going to be using before I can hire someone who knows it. Thus, I am relying on the expertise of you guys, some of who clearly work with this stuff everyday. Any help would be greatly appreciated, especially before I have this meeting in which we’ll be deciding what I’ll be doing for the next several months. Oh, and if there are any skilled web developers out there who’d like to move to San Antonio, Texas . . .

what is the best, most stable application server I can run on Solaris?

I can't answer that question directly, but I can provide some help: It is definitely not Sybase's EAServer.

jeff,

over the past six years, i've led the development of four major web-based applications, all using different suites of products. the rundown is as follows:

online banking site for 8th-largest US bank: apple webobjects, java/objective-c, no DB (interface to mainframe for back-end data), HP-UX deployment.

cellular network engineering tool for 2nd-largest US carrier: oracle app server, oracle DB, oracle XML toolsets, solaris deployment.

ticketing and reservation system for a major airline: bea weblogic app server, JSPs, java, jini, oracle DB, linux deployment (except solaris for oracle).

online trading interface to financial exchange: .NET architecture, ASP.NET pages, SQL server DB, (future) NT server deployment. this project is still in active development, and i'm beginning the process of planning the deployment now.

all of these were "mission critical" systems, security and reliability were major issues, and some were public revenue-generating applications.

my experience is that the combination that was the best to work with overall was weblogic/java/JSP/oracle. i did run into some problems with oracle on solaris (under certain high-load conditions, a transaction would hold onto a DML lock and never let go, even though it wasn't blocking, eventually leading to an application crash), but oracle developed a patch for us that took care of the problem. weblogic was rock-solid under linux, but i don't have experience running it on solaris. we did not use EJBs in our application, only JSPs and DB connection pooling, allowing us to license the much-less-expensive weblogic express product.

i would avoid oracle's application server and XML toolset. they do work, but the performance and reliability were definitely not there a year and a half ago. that may have improved by now, but my belief is that there are better products on the market.

i'm still wrapping my head around all of the .NET system components, but so far i'm not very impressed. it will be interesting to see how the deployment goes. this is my first time deploying a major MS-based application, and i'm sure there are lots of lessons to be learned along the way.

let me know if i can answer and specific questions.

--dan.

weblogic/java/JSP/oracle

So you're saying to use weblogic instead of Oracle 9i Application Server (and other tools)? And also that the difficulties our web people have had using Oracle 9i Application Server are not due to ignorance (as one of them has suggested to me)?

Can you tell me more about Weblogic? I'm delving into their website now, but any specific benefits you could list that Weblogic has over Oracle 9i would help me out for my meeting tomorrow.

I second the Weblogic/Oracle route. JBoss does many of the same things as Weblogic, but BEA is trying to move Weblogic into a more "business application server" instead of just a plain ol' application server like JBoss is (take a look at Weblogic Integrator to see this in action). The Weblogic Integrator tool is pretty cool, but very expensive.

Sounds like you have a good plan so far. As far as app server I am partial to open souce (jboss) but that is at least partially because the company I have been working for the last few years is to cheap to consider anything else. We have pushed 80,000+ users/day through very server CPU intensive promotional websites running jboss on a few cheap Intel boxen with no major issues using the Apache -> Tomcat/JBoss -> Oracle 8 combo.

We did run ATG's Dynamo for a couple of years (avoid it like the plaque) and evaluated Oracle's app server (too big, too weird, to unfinished feeling) as part of their reporting suite. I have never used weblogic personally, but have heard enough good things that I would consider it if I was looking for a new app server.

-Mike