Far more detail than you provide is needed to adequately answer this question.
The technologies that you use will be driven by your specific requirements, both functional and non-functional. So in order to know what will best fit your needs, you need to perform requirements engineering. Figure out exactly what the end user wants, and then you'll have a better idea of what tools you can use to get from where you are now to where you need to be. But it's important to focus on both the quality attributes and non-functional requirements as it is the functional requirements.
If you've never done requirements engineering before, I would highly recommend reading the works of Karl Wiegers. He has published two key books - Software Requirements and More About Software Requirements. The first book was required reading in the course I took on software requirements engineering. Wiegers also has a website called Process Impact, which might have some helpful resources and information.
Once you have your requirements, it will be much easier to determine which technology stack can best solve your problems.
However, I do have a few suggestions for you, in the interim:
You have experience with Java, so sticking with the Java environment is probably a safe bet. Don't use a technology to solve every problem that you come across just because you are familiar and feel safe, however. Make sure it can actually solve the problems that you are trying to solve. Otherwise, you are just creating more work for yourself and whoever else has to maintain your software.
Regardless of which solution you choose, the company is going to expect documentation. Depending on the terms of work, you will at least be expected to provide instructions on how to deploy the software and then instructions on how the end user can actually use the system you built. However, there's lots of other things that need to be documented, such as the agreed upon requirements, the design or the final state of implementation when you turn it over, defect reports, time reports, and so on. Make sure you know what you have to deliver, besides working software.
In terms of the database, you have choices between database servers (such as MySQL and PostgresSQL) and embedded databases (such as SQLite and HSQLDB). There are also the NoSQL (such as Hadoop) solutions for data stores. You might want to look into the capabilities of each one and see how you can best meet your requirements. You might need to deploy both, even, depending on the specific requirements. However, you can't choose until you have requirements.
Regardless of the database you use, you'll probably have to be comfortable with things like JDBC and various ORM layers. If you decide to go the web app route, you'll have to be familiar and make choices between Struts, Spring, and a number of other web application frameworks. Be ready to evaluate a number of competing tools, libraries, and frameworks against your requirements. And don't be afraid to throw things away. I believe it was a tip in The Pragmatic Programmer - plan to throw one away. You are going to be making mistakes, and you need to learn from those mistakes throughout this project. It'll help you in the long run.
So, in short, figure out exactly what you have to build before you even try to start thinking about technologies. Given your post, you aren't providing enough information for any reasonable engineer to give any suggestions. And if you don't know or can't specify what you are building to another engineer, there's no way you can build it.
AJAX
I think your question boils down to, "Should my web application generate HTML on the client side or on the server side?" Client-side generation communicates to the server using AJAX, although the X (XML) has generally been replaced with JSON, but most people still call it AJAX because it sounds better. Server-side, the server just makes HTML on the server.
I have a lot of experience with XML and almost none with JSON. Everything I know about XML makes me suggest that you use JSON if at all possible.
AJAX Pros:
- Send less data over HTTP(S) so they can run faster.
- The server is essentially a web service so that other people (or you) can write their own clients. This may help when creating a mobile version of your site. Also, many inventions become popular for reasons their creator never intended. Services are friendlier to people finding new uses for your code.
- Looks like a newer application
AJAX Cons:
- Debugging JavaScript
- Complexity?
- The stuff you can do with JavaScript is often completely impossible for blind or handicapped people to use.
- May require more code total (bigger overall storage on your embedded device)
Client/Server
All web applications use client-server architecture. The HTTP protocol forces web applications to behave that way. AJAX uses a work-around for that design limitation, but the basic underlying model of HTTP is still client-server. I wouldn't get hung up on the whole thing about the best way to apply MVC to web applications. If you have to do MVC for political reasons, look at how Ruby/Rails does it. Actually, Rails is a great architecture to copy (or use).
Service vs. App.
A good service is almost always better than an application. But making a good service is hard! You may need to make the application before you can write a well-enough designed spec for a service. Don't make your job more difficult than it needs to be. For version 1, focus on making a great application. Until your application is relatively stable and you are sure it meets your user's requirements, having a service probably won't do you any good anyway. Designing the wrong service too early is a waste of time that keeps on wasting as you try to fix your service interface, and deal with the massive refactoring of both server and client code that will follow.
C/Web
Wow. I worked in C and Assembly for 3 years before I switched to web development. I cannot think of a worse language to write a web application in - especially from a security point of view. Input validation and output escaping are so critical... SANS releases a list of the most common errors every year. Buffer overflows, injections, cross-site issues (improper output encoding)... All of these errors are really easy to make in C or assembly. At least a language like Java has a String which is immune to overflows and an exception handling mechanism that generally prevents off-by-one errors from allowing malicious code to access system memory. Not to mention handling international character sets (use UTF-8 when possible).
If you need to use C for memory or firmware reasons, then that's what you have to do. Just be careful!
Browser Support
The first step to making a web application is discovering which browsers will be used by your clients? W3Schools and Wikipedia are both good sources of general statistics, but YMMV.
Where I work now we currently validate that our application only creates valid XHTML 1.0 transitional HTML. We also use the specific Doctype and formatting necessary to avoid Quirks Mode in IE, which makes cross-browser HTML easier to write (see tips on my blog). We test on the latest 3 versions of IE, plus Firefox and Chrome on Windows and Linux (Safari uses the same rendering engine as Chrome). With that validation and testing, our application pretty much works everywhere (Windows, Mac, Linux, iPhone, Android, etc.) except the BlackBerry.
The BlackBerry has never had a real browser with JavaScript, so we don't support it. BlackBerry users are used to not having a real web browser, so they don't complain. Maybe that's changing? I would try to ask a few clients what browsers they are using and make sure to test with those browsers.
Summary
All web sites are built on HTML and HTTP. Have a good reference for these technologies at hand while you are making your application. In the course of making an application, even with a toolkit, you will run across issues that require a basic understanding these technologies in order to solve them.
You probably also need to be comfortable with CSS, and image compression in order to make something that looks decent and responds quickly. JavaScript, web-servers, and browsers are additional areas of knowledge that you will ultimately need.
If you build your HTML on the server-side, your code base will probably be smaller and you may not need to learn JavaScript. The server-side model means your programmers will be writing (C?) code that generates HTML that they can look at directly before it is sent to the client. The AJAX model means your programmers will be writing JavaScript that generates HTML. I'm not aware of a lot of tools for validating or even viewing the HTML code generated by JavaScript within a browser, making it more difficult to program correctly.
Where I work now, we use a hybrid approach which occasionally involves Java code that generates JavaScript that generates HTML. If you guys are new to web development, that's not the place to start. I guess I would have to say that unless you have compelling reasons to use an AJAX model, I'd start with the older server-side-HTML-generation model and see how far it gets you.
Best Answer
Building a web application is absolutely more complicated and harder to build than client-server, for a given set of features. There are a variety of reasons and ideas I'll describe in no particular order.
The highest voted question of all time on this site is What technical details should a programmer of a web application consider before making the site public? In there, there are dozens of bulletpoints, and while a handful are general statements, the vast majority of them are indeed specific to web programming.
Where is the "What technical details should a programmer of a desktop application consider before making the site public?" question? Why doesn't it exist? Because everything that would be in that list is inherent to programming in general, and web programming has to be concerned about all of those in addition to the aspects in the linked question.
Let's compare similar aspects of applications that are both web-based and not. In my opinion, the difference between client/server and desktop applications is insignificant compared to the difference between those and web based.
The reason why the differential in capabilities is because web-based applications are so much more difficult and complex to build.
Many people are exited about node.js, who's chief value is that you can build the front end and back end for web apps in the same language. Node.js was first released in 2009. Since when have client/server/desktop apps been able to use the same language for front and back end? Since nearly always. Why are people using it? Because web development is so complicated people are willing to bring in javascripts problems and complexities in order to try to reduce complexity in the server/browser interface.
Browsers and the HTTP link adds significant complexity to web applications. Unless I am writing software to fly the space shuttle, I don't have to worry about an error 404 when trying to access some memory address or other resource, but web applications I often do. Losing total access to the disk is often not a significant concern for desktop apps, and gracefully crashing is usually considered appropriate enough. Losing the network on a web app not only happens often, and repeatedly, but is expected to be handled gracefully and resume connection. That's all on top of all the problems that can be happening inside the serverside or front end code.
The connection between the browser and http server does not maintain any significant state. In client/server and desktop apps, it trivially maintains as much state as you want to. Think of the dozens of frameworks and mountains of boilerplate for web frameworks trying to bridge that stateness gap in a sensible way. Thick client apps, you get that all for free.
Think of all the millions of person hours people have spent struggling with obnoxious gotchas in displaying sensible webpages, the days of making things line up in Internet Explorer. While desktop apps have plenty of gotchas as their own, I don't think something as seemingly simple as "making two columns the same size" has sucked so much of humanities work on the desktop as it has on the web. I think making stuff work cross-platform has been considerably easier than cross-browser.
Even if you try to cut down on some of this complexity by restricting what browsers people use, you can similarly tone down complexity of thick-client apps by restricting what OS they are using. The web app will always have more independently operating parts and will therefore result in more complex software.
Lastly .NET has no bearing on any of this, these are broad statements I believe to be true across all languages.
P.S. Obviously there is the "browser plugin" route but that basically combines the worst aspects of both so pretend that doesn't exist when trying to grok the ideas here.