There are many RIA frameworks popping up (flex, extjs, gwt to name very few).
If my server is written in Java, why not use java web start?
The benefits I see: I get to program in a language that is easy to debug (compared to javascript), I can use the same code in server and client side (validations, model objects). With SWT I get nice looking GUI.
Even if it means requiring a plugin in the browser (or using a cli tool), if my application is an enterprise application, does it matter?
For webstart you need Java installed on the client. For Flex Flash. For Silverlight .Net. For other RIA platforms a JavaScript enabled browser. It is a lot of product politic in that question.
And Java is very intenting, because "all seems to be a nail". Of course one of the great advantages of Java: same language, same knowledge, same code on every platform or environment (server/client/middleware).
For enterprise internal use, no it does'nt matter at all. If your biz is on the internet the decison is much more complicated (or even you have to offer the same functionality in diferent platforms).
The only contra argument is that in a lot of cases it's impossible to force the clients of your rich client app to have Java runtime installed on their machines. Everything else is a matter of taste, already existing knowledge and experience.
I think that until now the perfect client technology simply does not exist. We were excited about ajax and then there is another "hot" technology like Adobe Air. What is the difference between these techs and the "old-fashion" client-server apps? My friends we are back to the early 90s!
The AIR for example needs a runtime installed on the client machine, it has access to local system resources and communicates with the server using a binary protocol. On the other hand we are developing "RIA" applications (and very good ones :) using pure java swing clients communicating with the server through the Spring's binary remoting protocol. And i must say, in such a development life-cycle Java-Webstart is the winner. Especially in large-scale projects (and i mean laaaarge-scale, not just e-shops) in the java field i haven't found something more productive and maintainable (ah! maintainence... another big story) than this.
IMO if your users can live with a nice look-and-feel and you don't have to adopt another technology just because it is young and sexy use webstart. Put more work in your business model. After all enterprise apps is about business, not animations. And money is where the business is ;)
Yes I think it does matter, seeing that some big companies still have IE6 as their standard browser and as a requirement for web based applications. And those won't allow you to install any third party plugins into their dinosaur browser.
And you don't make a difference between RIA technologies that use existing browser technologies like JavaScript, CSS and HTML (including GWT which just generates client side JavaScript and ExtJS which is just a JavaScript Component library) and the ones that require an additional runtime environment (Flash, Flex or client side ).
Of course some things are easier to accomplish with proprietary or third party solutions (or you just have more knowledge in one of these platforms), but I still think that there is a huge potential in technologies that are standardized and already implemented in every modern browser (the differences between the browsers are slowly but steadily getting better, too).
If you ship it as a 3rd party application you can define a JRE as a System requirement, anyway but then instead of JavaWeb Start ship it as a normal Java Application as well.
Related
I would like to replace Java Applet which currently needs to use client's resources, i.e. external readers, and to communicate with a server via socket.
Reason:
1. I have thousands of client machines using this Java Applet program, and most of them are running out-dated JRE. When the Java Applet program is updated / added new features, all client machines will need updating the latest JRE.
Expected Solution:
The Java Applet program would be expected to be replaced by a web-based application, which allows to compile and run source code at client's side such that the new web-based application could still use client's resources and communicate with server via socket.
Can I use JavaScript to achieve it?
I would very appreciate your help/suggestion for this problem. Thank you!
JavaScript is a scripting language that gets evaluated in the browser.
I would not describe it as compiling and running but yes, it does mean you can run code in the client and is commonly used to create applications that run in the browser.
There's a staggering amount of frameworks that you can use to write your application. Take a look at the TodoMVC site to see the same TODO app created using several different frameworks.
If you come from Java applets, GWT may be interesting to look at.
If you wish to let the JavaScript client listen for messages from the server, take a look at websockets.
The smart card reader is going to be a problem, though!
See Architectures to access Smart Card from a generic browser? Or: How to bridge the gap from browser to PC/SC stack?
By the way:
The real issue with outdated JREs is not that your code will not run on old JREs, you can create perfectly fine applets using java 1.4 or java 5. Any libraries you may need you can deploy alongside your applet. The pain is a security problem. Anything but the latest version Java plugin is getting actively exploited and puts the user at risk. Occasionally, even the latest version is not safe.
try socket.io
I think this is the latest technology you can use to communicate with client browsers. it support the latest browsers and mobile browsers too.
hope this will help you.
Javascript has become very powerful with HTML 5.0. Here is a list of new elements that you can use to access all kinds of resources, including local files, audio, video, GPU rendering (canvas + WebGL) and GPU compute (WebCL). Here are even more things you can do, including database connections and networking. You can even create offline Javascript applications.
jQuery and jQuery layout make robust GUI development a lot easier. Rich tool suites, such as Google Closure offer optimization and a compiler for improving performance and detecting obvious mistakes early in the development process.
W3 offers useful stats for making an informed decision on how many users on average have access to which features. Note that the most annoying guy in that list arguably is IE8 due to it's lack of proper HTML 5.0 support.
In case you want to stick with Java, then one alternative would be to use my http://bck2brwsr.apidesign.org project. It's goal is to create small Java that can run in 100% of modern browsers without any plugin installed.
There are Java bindings to HTML (via knockout - one of the four most popular frameworks for HTML5) and that is why one can code whole business logic in Java and just render it via HTML. Should be enough to replace most of the applet UI.
In addition to that there is an experimental API to render on HTML canvas. People use it to write Java games that run in a pure browser.
There is a simple way to communicate with server via JSON REST API or via WebSockets. A live example is here.
What is the Microsoft version of an embedded Java web applet? Is there a good example of one on the web?
Also, why is the dynamic web dominated by ajax and not embedded applications?
Silverlight is probably the closest thing now.
As far as why the web is dominated by JS driven websites rather than embedded proprietary applications I'd venture to guess it's the openness of the resulting web pages. Almost every web browser out today ships with a JS engine, and most users run JS; this is important because it means the user doesn't have to have any other applications (beyond the browser) installed on their computer.
JavaScript driven sites are also more portable than embedded applications -- the developer only needs to worry about a browser being installed (though perhaps a particular browser), not what operating system the end user is running. In terms of being on the web, only having to worry about browsers is better than having to worry about browsers and operating systems.
Furthermore, the pages that result from JS execution are selectable, the text can be copied and pasted -- in general, JS-driven websites are often more accessible (though often not as accessible as plain-old-text websites).
Perhaps something that helped JS/Ajax rise to the top was that it could so easily access to the DOM, so it plays nice with HTML (and the existing web infrastructure).
An ActiveX control?
Also, to your second question, well these "embedded applications" as you call them aren't really web applications. They are components that require browsers to support some sort of way of hosting them that are outside of the realm of traditional Web standards and specifications. As for why these applications don't "dominate" the markert, they tend to break out of the way the web works and many kinds of platforms and devices don't support them such as mobile phones.
The Microsoft equivalent of an "applet" is roughly an activeX control, although they are only vaugely similar - the similarity is that they are both embeddable into the browser. The most notable difference other than windows vs cross platform is in the region of security. With ActiveX, it is all or nothing - you either don't run it, or you trust it with everything - the activeX control runs as a regular windows "program" and has the same level of access as other programs running under your account. With an applet, security is more finely controlled, with the default being a controlled environment - the "sandbox".
As to why AJAX is more popular might be considered a subjective question, but from the technical perspective, some objective points in favor are:
it is implemented on top of a browser model that aims to provide a safe/secure execution environment
is cross platform (in as much as the browsers adhering to the various standards involved.)
has a suite of development tools and libraries for getting results quick
it can manipulate the components in the browser rather than working inside an isolated embedded box
it provides a better end user experience - seamless integration with the webpage with no security warnings, certificates, popups etc.
You could consider ActiveX or Silverlight both as alternatives to Java Applets.
Ajax is built on open standards, is natively supported by most modern browsers without requiring a plugin download, and when done correctly is often the best option from a performance standpoint.
I am a fresher in web developing , is I ve to study applets?
If you are a Java person, maybe look at JavaFX instead (even though it is not clear yet if that technology will take off any more than applets did).
If you are a web design person, do not even think about it before you got acquainted with Flash and HTML5. Applets are quite marginal at this point.
Most folks say no, but I still see a lot of great uses for Applets and in fact have seen really complex commercial UIs coded within the context of an applet.
in a short word, no, applets are a dead technology for the general purpose web.
on intranets with lots of bandwith and controlled client environments they maybe of some valid use.
look at Google Web Toolkit (GWT) as an alternative to creating applets.
Adobe Flex is also a good alternative now.
If you want an embedded client application, the Java Web Start (the better Google keyword is JNLP) is less or more the successor of the legacy Java Applet. Alternatives to this are Adobe Flash and MS ClickOnce.
If you want an RIA (Rich Internet Application), then JavaFX is the better Java based choice. Alternatives to this are the MS SilverLight, Adobe Air and Adobe Flex.
Apart from JavaFX, Flash, you can learn about Adobe AIR and Microsoft Silverlight. They are kind of extending the limits of what was earlier possible with just Flash
There is still one thing that I know of that a Java applet can do and Silverlight, Flex (non-AIR), etc can't do:
Drag and drop from the filesystem.
Flex offers a o/s based browse and select filesystem access. Silverlight has a similar functionality. But to the best of my knowledge if you want the user to drag a file from Windows Explorer etc. into a web-site based control, Java applets are pretty much your only choice. You could create a Flex based app using Adobe AIR that can ask the filesystem outside the o/s browse and select dialog but I'm not convinced the AIR install base is adequate yet. Probably depends on your target customer (early adopter, install whatever you say to vs. stable corporate user with IT lockdown on their workstation).
If someone knows otherwise for certain, please comment!
But to answer the original question, unless you need the drag and drop filesystem to web functionality, I would spend your time on Flex. Silverlight and Java FX can't compete with Flash for market penetration. Since Flex compiles to flash, it has a very high install base (>95% of internet enabled computers) and its base updates to the newest version frequently. Inserting a flash file into a browser is a easier than the arcane art of applets.
if you want/might get a job where you maintain old applications then probably you will deal with Applets.
For new projects, dont get close to it.
Has anyone had experience taking a full-fledged Java desktop application and replicating the functionality using Flex?
If you have, what are some of the biggest things to watch out for or pay attention to?
What are some recommendations you can make based on your experience?
There could be any number of issues to watch out for. Here's a few that just come to the top of my head:
Flash Player restrictions that do not exist in the JVM, such as the ability to reach "outside" of the Player's bounds rectangle (and myriad others).
ActionScript 3 has no equivalent of java.lang.reflect.Proxy, unfortunately. This means that (so far) there are no decent mock object frameworks, and limitations with respect to reflection in general.
I am not aware of any AOP capabilities on the order of what you will find in Java.
Whether or not the Java application is using libraries that have no equivalent in Flex and which you do not wish to write yourself.
Java applications can call out to native code with the JNI, whereas this is not yet possible with the Flash Player.
Even if by "Flex" you include the Adobe AIR platform, the environment tends to be much more restricted in general than the JVM. However, don't let that discourage you - you get a lot of benefits from using Flex, such as an ubiquitous runtime, a great language and component development framework, etc. If your Java desktop application is an RIA, then Flex is probably a good candidate for a port.
I'm not sure if replacing a full-fledged Java desktop application with Flex is the best alternative. From Adobe Flex page: Flex is a highly productive, free open source framework for building and maintaining expressive web applications that deploy consistently on all major browsers, desktops, and operating systems.
Adobe AIR is probably a better replacement for desktop applications, if you're considering Adobe realms of products.
I need to implement webservices in an upcoming project and wanted to know what are the main points to base the decision on whether to implement using java or .NET
I'm a C++er...
If you're a Java shop use Java. If you're a .NET shop use .NET.
There really is no difference that makes one of the two languages superior to the other in regards to web services.
Possible consideration - .NET pre 3.5 only provided support for SOAP based services, but I believe the 3.5 WCF offers REST and SOAP now.
There's no real difference from programmer's point of view (implementation).
For me, a reason to pick Java is that all tools and infrastructure are free/open source. OS, deployment web server, databases, IDEs and developer tools.
I have plenty of experience with both, and both will certainly do the job.
However I tend to prefer Java over .Net for things like web services for the following reasons:
It's cross-platform, which gives you much better options on the hosting side (e.g. running a big Linux cluster on Amazon EC2)
The library ecosystem is larger and more mature, especially on the server side.
I prefer the more flexible open source philosophy to "the only way is Microsoft". Vendor lock-in is always a bad idea for your enterprise architecture in the long run.
You can optionally use awesome languages like Clojure or Scala on the JVM
Ultimately though, I'd go with the one your team has the most skills with. This will determine what you are most productive with, which is usually most important if your main objective is to deliver value quickly.
It's a personal decision, usually determined by the technology already in place or the skill set of the developer(s) writing the services.
i've never really developed web services in java, but i have in .NET and if you're using Visual Studio they're an absolute cinch to whip up (i expect they're a little more difficult to do without the aid of VS).
if you're already working in java, and don't have any .NET stuff in place, stick with java - it'll save you a lot of money (if you were to get Visual Studio in, as i mentioned), and possibly some time involved in learning the specifics of .NET
In my experience, Web Services are a bit more tightly integrated into Visual Studio than they are into Java's editors.
The Eclipse IDE doesn't even have JAX-WS (Java standard web services stack) support built in, opting to use Apache Axis 1 instead.
Netbeans supports JAX-WS, though.
I personally prefer .NET to Java for many reasons I don't want to go through, since it doesn't really matter and is more a personal preference than a strict guideline I can recommend.
If you have Java infrastructure in place or using a platform other than Windows for your server applications, I strongly suggest Java. However, if you don't have anything in place and running on Windows platform, .NET is pretty cool in that area (WCF/ASMX/WSE/...).
As you say you're a C++ - er you'll probably find .NET easier as you can target it directly from C++.
I'm a Java guy, but I think Web Services are easier to code in .NET. Visual Studio takes care of everything, in Java it takes a bit to get started.
A bit of a problem in some projects with JAX-WS is, that SUN ships the "old" version 2.0 with Java 6. If you want to use the current version, it's some work to make it run with Java 5 and Java 6.
If your app must be portable, you should obviously choose Java. Otherwise I would say it's just a choice of your preferred language, since the above issues are really small (maybe you want to choose Axis or something else anyway, I haven't worked with something other than JAX-WS yet).
IMO if you want to do SOAP, then its a heck of a lot easier to use .NET and WCF. However, I've found REST to be a bit tricky with WCF, and had to implement a custom XML parser to do it instead of using their built-in one.
You probably want to consider your hosting environment too. If you are going to serve this from Windows hardware, you can drop .NET WCF web services into IIS. If you are going to run a Linux/Solaris server, then it isn't even a question...
I suggest implementation with JSP ,it provides a robust platform for development
I prefer JSP to ASP or any microsoft techonolgy!