I have seen a few examples where the architecture is that there is java on the server side and c# on the client - what makes this combination so good? why would .net on both sides not be a better choice (or in fact, java on both sides?)
added later: in lots of cases, the java is hosted on a windows server itself, i think via tomcat (not 100% sure) - what's the motivation here?
Java is frequently used on the back-end (and has become the de-facto standard) for a number of reasons:
Java can run on various operating systems transparently, from Windows development workstations to dedicated unix servers.
Java enforces a modular, object-oriented approach to coding, which allows for large-scale systems to be written (hopefully) without becoming unmanageable. (this is also true of C#/.NET, but not true of other back-end languages such as Perl or Python)
Java is frequently used in back-end systems (the more popular a language is for a particular application, the likelier it is that there are mature libraries and tools in that language for that particular application)
C# has great tools and libraries for designing UIs in Windows. Java's operating system (OS)-independent nature provides fewer tools for the particular quirks of an OS's UI, whereas C# is designed and maintained by Microsoft, for the purpose of writing Windows applications.
Well, there are a lot of cases where .NET is used at both ends (and I would guess ditto for Java). But my guess for the motivation behind Java-server/.NET-client architectures is that the application is targeting Unix as the server OS, either for cost or reliability reasons, or because it needs to fit into an existing Unix server environment (e.g. working closely with existing Unix apps), but is targeting Windows as the client platform. (I think Java is probably much less common where Windows is also being used as the server platform; no figures to back this up though.)
If a Unix server OS is assumed, then Java is a very productive choice, well supported with lots of libraries but with a larger developer base (at least in "enterprisey" environments), and more "management" recognition, than alternatives such as Perl, Ruby or Python.
Conversely, .NET is the better fit for the Windows client, because it has much better support for building Windows GUIs. It's not just the tooling: the Java GUI APIs themselves (e.g. Swing) tend to prefer cross-platform similarity over a native look and feel, and therefore tend to result in apps that don't look or behave like Windows applications. (I am generalising a bit here -- sorry!)
Data interchange formats like JSON make it far less important that the systems on either side of the connection are the same low level technology.
Java is a very well tested and supported language for servers, whilst C# has great tools for building GUI's.
Java is considered more mature, which is a good attribute for a server, whereas C# has better integration with/similar look and feel to windows and office (which the clients like)
Most servers are either Windows or *nix based. So at the server, either Java or .NET/C# (via mono on *nix) would be perfectly good.
Java has better support for different client devices, but in many ways that requirement is being replaces by the much better HTML support at most clients - at least for online devices.
For a installed client application, then arguably Java has the better portability - but with things like Compact Framework, Micro Framework, Silverlight, etc .NET is catching up.
Personally (due to job role), I care mainly what is at the server; .NET/C# has never let me down - but I'm not a Java developer, so I can't contrast directly. From work on open source projects I know there is a good community of people out there using mono on the server.
At the client, tools like WPF offer a first rate GUI experience, with .NET's support for winforms being useful for regular windows apps. But since a lot of the WPF architectureis common with Silverlight (with Moonlight as the mono twin for *nix etc), this allows the experience to be used on non-Windows clients too.
As far as Java is concerned two things
Linux. Its reliable and cheap. One of the many reasons enterprises use a lot of Linux for Java because they don't have to reboot boxes after Patch Tuesday.
Hotspot. Its one of the wonders of the modern world - amazing performance.
Fortyrunner, I haven't seen a single benchmark where a hotspot JVM will beat MS CLR.
On the server side Java has proven to be robust and scalable and it is available on platforms that .NET can only dream about. Hence if you want the most choices in hardware Java is an excellent choice - this includes very large machines with many CPU's as well as lots of clustered cheap x86 boxes.
If you have .NET on the server side you must use Windows, and Windows simply doesn't scale well hardware wise.
Related
I'm looking for a technology which is targeting on building distributed applications. My friend adviced me to use CORBA (Java & C++ combination) . But I have read it's sort of obsolete stuff. I'm planning to write rather simple distributed application. What solutions would you advice to use? Thanks!
If you want to distribute your code logic to multiple servers and have it managed as a single entity, I would recommend CloudIQ Platform from Appistry. You can deploy Java, .NET and C/C++ code to the framework. From an administrative point of view, the servers work and act as one. When you submit a request for execution, the framework distributes the request to the best available worker, performing load balancing. With this framework, you can have producer/consumer, scatter/gather, and other parallel types of jobs.
The framework also monitors the execution of jobs, so if there is any type of hardware failure, other machines will get allocated the jobs that were running on the failed server.
CORBA is quite old. To choose a library or framework, the questions are: why do you want it to be distributed? (what's the goal? performance / parallelization? scalability? physical constraints on locations of parts of the system?) Which sort of nodes will be running the various parts? What languages would you rather use?
Recommend using ICE(Internet Communications Engine), ICE can support multiple operating system platform (Windows, Linux, Solars, Mac OS, iOS, Android...), multiple developing language (C++, Java, .NET, Python, Ruby, PHP), and it is simpler.
You can use SOAP web services. I'm currently developing distributed testing system on Python & .NET using using SOAP and it is easy to write and deploy.
There are a lot of different SOAP server/client libraries for different languages and platforms.
Yes, CORBA, and technologies like COM and DCOM are all pretty much obsolete... I am not sure exactly what you want to accomplish, but I would look towards .NET remoting to build distributed applications. If your application is really simple, you can even use mailslots or named pipes to pass simple data across a network.
As sinelaw mentioned, there are many questions before a good suggestion can be made, but, you may want to look at REST (http://en.wikipedia.org/wiki/Representational_State_Transfer) as a way to transfer data between applications. REST is nice in that what it can accept and return are flexible, for example, you can upload a file and return a PDF. Though it is used on http, that isn't the only allowed protocol. It is language/platform agnostic.
If you want to go with something that is standardized then SOAP or REST is probably your best bet, if you want to be platform-independent. If you don't mind being restricted to Java/JVM or .NET then there are other options, but that becomes very restricting.
What type of data is being passed? How critical is security? What platforms/languages should be usable? What is the purpose of the program, the goal?
If you want a portable solution that can also be used with different protocols, WCF on Mono might be a good fit
For .Net I suggest you WCF , it's quite simple to implement and very flexible, and about CORBA it's a good choice if your goal is to understand deeply distributed applications, but it's not more recommended for real projects, currently is very difficult to find developers mastering CORBA.
I'm an inquisitive .NET student without any commercial working knowledge and I have been puzzled by what exactlty are .NET languages meant for?
Q1.If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications? (My dream job is to develop standalone small Windows applications.)
Q2.Are most "major" Windows applications developed using C/C++? e.g. word processing applications like MS Word or OpenOffice; photo editing software like ACD See or Photoshop; MSN or Yahoo Messenger; disc burners... Is .NET too slow and too indirect to handle these kinds of tasks?
Q3.Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications Because it's too slow and too indirect for major software applications?
Q4.I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages? Do they use MFC to access Windows API which is also outdated in new versions of Windows(backward compatible but not encouraged by Windows)?
Q5.If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
Thanks a lot for your industrial insight!
If you look on job websites, .NET seems mainly used for web applications, not much for Windows applications?
1) .NET is not very common for "mainstream" desktop applications, if you consider mainstream to be Photoshop, etc. This is often more due to the fact that mainstream applications are based on code that was written long before .NET came around, and those applications are never rewritten, only grown. They carry a huge amount of legacy code from previous versions.
Are most "major" Windows applications developed using C/C++?
2a) See #1.
Is .NET too slow and too indirect to handle these kinds of tasks?
2b) Absolutely not. .NET can be blisteringly fast or dismally slow. Like with any tool, it depends on who is using it.
Are .NET languages mostly only used in SIMPLE business applications involving database backend? E.g. payroll or GPS applications
3) Payroll or GPS are hardly simple. Line of Business (LOB) applications can be immensely complex and .NET is often a good match for these precisely because they are so complicated.
I thought for the last few years .NET was the only development tool encouraged by Microsoft for Windows applications and C/C++ are outdated languages?
4) That is wrong. C/C++ are not outdated, they are just different. They provide a more precise level of control over the machine in exchange for longer and more difficult development time.
If C/C++ are the main tools for major standalone Windows Applications, then the (slow) managed code approach is only a joke? Or the dominance of C/C++ is due to most major applications are older than .NET? Can you give me some famous names of software developed using .NET?
5) Dominance is very much inherited. Again, .NET is not slow. Mainstream applications are well-known in large part because they have been around longer than .NET, so there's no reason to expect many, if any, .NET applications as well-known or popular as Word or Photoshop. Several years in the future, it's not unreasonable to expect some famous applications to arise that are .NET-based.
Edit:
Some people seem to be confused and believe that somewhere in this answer, it is asserted that .NET is as fast as c++. The only argument present is that both .NET and c++ are fast enough to run most mainstream applications. And anyone who thinks development time in c++ and .NET are equal, all other things being equal, hasn't done much development in one of the two :)
.NET is increasingly becoming the language of choice for most Windows development, including standalone desktop applications.
That being said, C/C++ are still used heavily in this space. However, on Windows, much of the "cutting edge" work is done in .NET, or a mix of .NET with native code.
The latter is, frankly, probably where the most exciting work is happening. It allows you to have the "close to metal" feel of native code when required, but still have all of the power provided by the newest .NET framework (such as WPF) for the user interface layer and non-performance critical sections. This is becoming more common over time - for example, Visual Studio is still largely native (C++) code, but the entire user interface was written using WPF (.NET).
I do nothing but desktop Windows development. I personally prefer to use .NET for everything I possibly can - and revert to C/C++ for the very small (and increasingly smaller) portions where .NET doesn't make sense.
One issue I take with your question is that you ask a factual question ("Are most "major" Windows applications developed using C/C++?") and judgmental/causation question ("Is .NET too slow and too indirect to handle these kinds of tasks?") in one go.
It is indeed true that most Windows desktop applications (e.g. Microsoft Office, Adobe Photoshop and the likes) are written in native code. However it is also quite true that on server side, at least in Microsoft stack, it is all ASP.NET, i.e. managed code.
Consider now that performance requirements of a typical web application are much more strict than that of a typical desktop application - after all, a desktop application only have one user, when a server application may have thousands and thousands. So the causation link you imply sounds weak.
As the others have pointed out, there are many requirements at play when choosing implementation technique for your desktop app. It might be portability, tradition, existing code base, training of your developers, existence of managed wrappers for particular APIs (historically Windows was often lacking in the latter) and many other factors.
For the specific examples of "all managed" desktop apps I would cite ReSharper - it is a fully .Net desktop application with non-trivial user interface and logic. Visual Studio 2010 also have considerable portions (including UI/presentation layer) written in managed code.
There are a few main issues that, I believe, still contribute to the relative lack of commerical .NET applications (the type you buy in a box at your local software store):
Requiring customers to (possibly) download the correct version of the framework runtime and/or install it before running your app.
Where ultra-high performance is required, .NET array/collection bounds checking (managed code protection in general) is obviously slower than languages/tools that don't do this for you.
The view that JIT compilation causes slower startup times.
There is often little business value in re-writing 1000's of lines of working C/C++ code in .NET.
I'm not saying whether these issues are valid or not, just trying to answer your question as to why there is still a relative a lack of commerical (shrink-wrapped) .NET software.
.NET is certainly used for standalone applications, though determining exact percentages is next to impossible.
Yes they're mostly done with older languages. Many certainly could be done with .NET, but you'd need a lot of incentive to rewrite something as large as Word, Photoshop, etc., from the ground up.
Not necessarily, but it can look that way simply because a huge percentage of business applications can be (and are) written as database front-ends.
I don't think MS has a really unified message here -- they've certainly put a lot of work into .NET, but they also continue to develop and improve alternatives such as MFC (probably at least in part because they use it themselves).
Some of both. More than speed, C++ and C give flexibility, portability (e.g., Office for the Mac) and greater ability to distinguish your application from the others.
Most large Windows applications are C++ because they were written before .NET existed. It would be pointless spending 2 years of development time rewriting Microsoft Office (say) in .NET, only have exactly what you started with two years ago as the result.
Instead, most large software application build .NET into them slowly. Look at VSTO, for instance, for a great example of .NET interoperability in a C++ app.
On the other hand, Microsoft have released a number of software packages that were written entirely (or primarily) in .NET languages. Expression Blend was probably their first. Visual Studio 2010 (which is largely WPF-based) is the latest.
ASP.NET is very large because you control the hardware. It dosen't matter if your users are on linux or on mac. The page renders and works. When you have the hardware as a parameter, people are wary of .NET which (mono-aside) is prettymuch windows exclusive. (Mono 'works' but it's less accepted than other x-platform approaches).
.NET also requires a download to be installer (.NET Framework). There's a lot of friction for users installing things to USE your thing, it's been a small barrier in XP, but now that 3.0/3.5 is baked into vista/win7 it's becoming a non-issue.
In the past, yes. These days, not as much. (Correct me if i'm wrong, cuz it's very possible i am) I believe VStudio 2010, and Office 2007+ are now developed in .NET since they don't heavily require on maximum performance. C/C++ is still faster for games, but even some indie developers are building games for xbox/pc on XNA (DX for .NET, sorta)
No. .NET isn't as slow as it used to. There are Lots of big big applications built in .NET now because it offers a wide variety of features to develop BIG applications FASTER, BETTER, and MORE STABLE.
.NET does not use MFC. Winforms hook GDI+, and WPF hooks the Windows Presentation Foundation to do it's api calls. .NET is for the most part a re-write, but some things (like direct file-i/o, are wrapped down to the windows API)
Software is developed in C/C++ because it's a) fast b) commonly known. But with today's new programmers, it's shifting I think. I also believe the new versions of Sony Vegas have been re-written for .NET, but once again I may be wrong. The key to remember is that .NET isn't as slow as it used to be, MS has bee working on the performance issue hard because they want to sell .NET for windows development.
Windows itself is not written in .NET. There's good reason for that...
One of the major problems for .NET in mainstream applications is that the ISV's producing them would like to have portable code. Photoshop for instance has a very succesful Mac OSX version. Of course, such portability is precisely not the goal of Microsoft.
Now, for the Web this doesn't matter too much. You can use .Net on the server-side and still produce a Safari-compatible website.
IMHO the tide will come whenever IE will become a managed application.
If you want to develop LOB apps for small shops that can't afford to hire programmers, and you wish to offer max features for minimum work, write them in MS-Access. Serious.
https://stackoverflow.com/questions/2437387/is-ms-access-still-the-most-efficient-rad-tool-for-small-scale-custom-apps
I am quite aware of both java and C# .Net .when i try to create a new windows application which are the factors that decide which technology should be opted?
I know of one thing ,for great and faster UI development Visual studio helps a lot.
There are several factors I would consider...
What are your programmers used to working with already? What third party libraries are you likely to need, what's available on both platforms?
Does platform independence matter to you?
Would LinQ be advantageous?
If you're starting from scratch, costs for the platforms?
Both platforms have strong communities around them...
Hope this helps...
Dotnet is pretty much native in Windows which obviously makes it more suited to writing Windows programs. Using Java in a Windows-only environment makes it much harder for you since it effectively just adds another unnecessary API layer.
You will soon realise that all integration points between your Java code and Windows are a bit problematic. For instance, creating installation programs, access file system, reading/writing the registry, starting/stopping services, task bar icons, using Windows GUI components (media player, IE...), help file system...
It all boils down to this imo: The Dotnet framework is much richer in terms of functionality than the Java dito, mainly becuase Java is cross-platform and thus needs a "one-size-fit-all" approach to its API. My experience is that you will only get frustrated trying to "emulate" a Windows native program in Java.
Choose the one with which you are most familiar. The two platforms are different enough that skills from one does not transfer easily to the other.
In any case, try making a trivial application in both your scenarios and see how it works for you. The initial impression is important as it is probably indicative of how well the rest of the work will be.
It also depends on what kind of windows application you want to build. If it's just a question of building a simple standalone application then, considering you know both languages equally well, I wouldn't hesitate and would go for a 100% microsoft solution, especially if you have to do specific things like accessing ActiveDirectory, the windows registry, etc.
Not that you can't do it in Java : you can always use AD through LDAP in Java for example, but the APIs are just "a bit" more complicated than the .Net ones (try to decode objectSIDs in Java without a few tricks).
Now if you have to build an enterprise app. I just feel that popular frameworks like Spring and Hibernate are always coming out after their Java counterparts (disclaimer : this is a personal opinion; I didn't do any research on this, thoroughly comparing frameworks in both languages, but that's just the feeling I have). I don't know how good the .Net implementations are though, so I don't have a point of view on that. I just remember writing .Net 2.0 apps and not liking ADO.Net at all.
My view is that the frameworks I like do exist in both languages, but they are first developed for Java, then ported to .Net.
Now I'm not the kind of developer trying to defend his favourite language over the others. If I don't have external constraints to develop, then I choose whatever language gets my app up and running faster and in the most efficient way.
...But with java you will have crossplatform application on scratch.
Also coding UI in java is not difficult - if you read some guides before and use some frameworks as swing application framework or SWT framework.
If its Exclusively for Windows then .Net is best bet.
Yeah for a pure cross platform application Java can't be beat, but if you can manage it Silverlight is a subset of WPF and a pretty compelling cross-platform proposition on its own.
Productivity-wise I think WPF has an edge as it has a nice XAML markup language that can be easily created with the built-in designer in VS.NET or integrates nicely with MS' suite of expression products.
While this stems from the age-old debate between Java and .NET, I'm interested in the merits of these two technologies in terms of SOA/web services.
I'm starting a new project writing web services. I don't have extensive experience writing them in either Java or C#, and I'm open to using either a Microsoft stack (running IIS) or a Linux stack (running Tomcat). So far in my research, the complexity of the two languages seems to be about equal.
I'll be running a MySQL database (SQL Server is out of the question). Database access thus has no bearing on the rest of the stack.
I will be consuming REST services (and possibly SOAP as well), and exposing SOAP services.
What are the advantages or disadvantages of these two technologies in terms of ease of use, complexity, typical development time, total cost of ownership (esp. maintenance costs), etc.? Which has better integration to existing security and authentication frameworks (e.g., CAS, LDAP, or OAuth)?
While I am a java proponent and have little C# experience, I will honestly say they will likely be about equal, and you should go with whatever language you are most familiar with and comfortable in programming.
On the Java side, both exposing and consuming web services (SOAP or REST) can be easily done via open source libraries (and there may even be some stuff built into the JDK at this point, although usually they are a bit behind the open source community), one of the most popular being Spring. This will do for you all the complexity and plumbing around creating and consuming SOAP, and exposing or consuming REST.
For SOAP:
For REST:
http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/
http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/
For SOAP:
http://static.springsource.org/spring-ws/sites/1.5/
Note Spring is just one option (but a good one), but my overall point is don't write the plumbing yourself, choose an existing framework to do it for you and it shouldn't matter what language you use.
As mentioned I don't know much about C# but what I've found is they usually take the good parts of the core JDK and the open source java community and build it into the language, so there may be some nice native stuff in C# that mirrors what Spring has done for Java.
Is it worthwhile learning C# if you are a Linux user? There is Mono but it seems destined to always be behind the curve with the constant threat of MS action if they start to lose money.
Currently I am leaning more towards Java as its is fully GPLed and there are no major threats of software patents. It already has a big oss community behind it and has a solid reputation on the server whereas C# still needs to prove itself there.
The big advantage for C# programmers is that they are cheaper than Java developers. I also wonder exactly how portable C# code is though. Can one simply take a C# app written to target Mono and run it on windows?
I've written a number of C# command-line programs, specifically to run as distributed simulation engines, that were targeted for Ubuntu. They work perfectly there or on Windows.
It's hard to say what the future holds, but C# is a powerful language and I think it's worth learning even just for our personal growth. I despise Windows myself but have been writing C# for a while (for Windows mostly) since it pays the bills.
Novell uses Mono extensively for their Linux applications and I think that their relationship with Microsoft adds some weight to the idea that .NET for Linux will stick around.
Here's a list of some of the companies using Mono.
"on the server whereas C# still needs
to proof itself there"
You do know MySpace is built ontop of ASP.NET, right? Millions of hits a day running off a C# backend.
Sorry for the flame-bait, but I've personally had more portability success with mono, than java. Not a blanket statement, just my experience.
This question has already been asked and answered many times on SO.
Is Mono ready for prime time?
Why Use Mono?
Given your scenario, me personally I would learn Java, as you will find the transition into C# further down the line, quite smooth. Also having Java under your belt is a very good thing. I would say Java is much more portable than C# although you have the option of using the Compact Framework, which will be quicker to bootstrap with your program.
I work for a company that uses both Java and C#. I prefer C# because I think Visual Studio blows away Eclipse, and I just like the language better. However, I think you might do better learning Java in your case. You have more flexibility both for your project and career-wise. You can learn C# anytime.
C# is a nice language, and I find it much easier to work with than C/C++, especially for GTK applications.
I also think that learning C# would be a much better investment than learning Java. I'm saying this for no other reason than my personal taste, but I also honestly and objectively believe that C# will have a better future than Java.
As for running Mono apps on Windows, you can usually do this without a hassle, but if it's a GUI application, you will either have to create a Windows version that uses Winforms, or your users will have to install GTK for Windows. Either way, your applications will have a much better look and feel than Java applications on both platforms.
Finally, I don't think M$ will take legal action against Mono anytime soon.
It works very nice. IMHO you should use Mono from the development site (www.go-mono.com) rather than version provided with your distribution.
Also you could try dry-running it with VMWare machine that is also avaliable on the official site.