Develop Reference

Tomcat API vs other APIs

I've been learning Tomcat and servlets recently. Now I came to realise that the Oracle API and the Tomcat API are at least somewhat different. I know the Oracle API should be wider, but still even in the limits of Tomcat operation, they seem to have completely different packages, etc.
This may seem silly, but I can't find any answer. Could someone please explain the differences? And in practical terms, if I build a service that runs under Tomcat, will it also run in, say, Glassfish, without any refactoring of imports?
--- EDIT ---
So, apparently I mistook Tomcat API for Servlet API, etc.
The solution is not to look at the Tomcat Javadocs in the shot above, but at Servlet Javadoc, or whatever is in question. The list in the pic can be found at Apache Tomcat 8 Documentation Index, on the left, slightly down.
Thanks, Andreas and EJP.

Java Enterprise Edition
What you call the “Oracle API” is actually the Java Enterprise Edition (Jave EE) specification. I suggest you avoid using your misnomer.
Java EE is a vast collection of dozens of varied technologies layered on top of Java Standard Edition (Java SE). Various implementations of Java EE support different pieces, not necessarily all of them.
Subsets of technologies
The Apache Tomcat project, and similarly the Eclipse Jetty project and others, intentionally implement only these technologies:
Java Servlet
JavaServer Pages (JSP)
Java Expression Language
Java WebSocket
These few APIs are just a small, but vital, subset of Java EE.
The Tomcat API you linked is specific to Tomcat’s implementation. Developers would only very rarely go through that API. Instead we stick to the interfaces published in Servlet, JSP, EL, and WebSocket specifications all published as JSRs. Sticking to the specs means your web app can be deployed on other implementations as an alternative to Tomcat should the need ever arise.
Web Profile
The Java EE Web Profile is a specification that includes Servlet and JSP APIs along with several more, but still a subset of all the possible Java EE technologies. Apache TomEE is one implementation of the Web Profile, that starts with Tomcat and adds more libraries. Another example is Glassfish, which is/was available in either a complete Java EE edition or a stripped-down Web Profile edition. See the Question, What is different about the Java EE packages? (SDK/normal vs Web Profile).
“Full” implementations
Some products implement all (or nearly so) of the Java EE specifications.
Sometimes this is described as a "full" implementation. I consider that label misleading as it implies the subset implementations are missing or lacking something needed. Quite the opposite. You should always use the leanest implementation that includes only the parts you need. More heavily laden servers take more memory, start and stop more slowly, and may cost more money. For example, I build and deploy highly interactive desktop-style web apps using only Apache Tomcat 8 with Vaadin 7 on top of Java 8 Standard Edition (SE) on Mac OS X.
Also keep in mind that many of the Java EE technologies can standalone, separate from a full Java EE implementation. So you can start with a leaner implementation and then add the libraries for just the few individual technologies you need. For example, Bean Validation can be used on Tomcat by adding the JAR file of an implementation.

Kaazing vs jWebsocket

Can somebody please compare these two websocket servers. I have to select one of them; I need an expert opinion due to newbie in multiplayer "online" gaming. I would probably have the flash client. What challenges I could face using one over other.
thanks in advance.

Full disclosure: I work for Kaazing and I have not used jWebSocket myself.
A couple of quick points:
0) Production vs. Beta
Kaazing is production-quality software. The download link on the jWebSocket web page points me to a beta version of the product.
1) Client Technologies
Kaazing provides WebSocket libraries for multiple client technologies (JavaScript, Java, .NET/Silverlight, and Flash), It looks like jWebSocket provides JavaScript and Java. You mention you would need a Flash client and AFAIK only Kaazing provides that. jWebSocket uses Flash for emulation (see the next point).
Note: Kaazing now provides AngularJS, ReactJS, Objective-C (iOS), Xamarin (.NET with support for iOS and Android), Java, .NET, and Android clients. However support for SilverLight and Flash have been deprecated.
2) Emulation (for browsers that do not support WebSocket)
jWebSocket requires Flash, Kaazing does not.
Note that Flash emulation for secure WebSocket (wss://) requires you to open a separate port for the Flash x-domain policy file. In many enterprises this is a non-starter.
3) Protocol Support
Kaazing offers a wide range of higher-level protocols on top of WebSocket: JMS (can run against any back-end JMS message broker), STOMP, AMQP, XMPP, etc. I don't know what jWebSocket does in this space.
4) Enterprise Deployment
It is easy to configure the Kaazing WebSocket Gateway in conjunction with existing Directory services (LDAP). It supports Single Sign-On, and the gateway can easily be clustered for HA purposes (again, not quite sure what jWebSocket does here.)
Please take a look at the documentation for these features:
Security configuration:
Using the Gateway to Support High Availability
Secure Network Traffic with the Gateway
5) Open Source
jWebSocket is open source, Kaazing has both an open source Community Edition and an Enterprise Edition.
Hope this helps for now!

I am a jWebSocket developer, we are currently working in the first production version of jWebSocket, I will just mention some advantages of jWebSocket:
- Multiple clients ( JavaScript, C#, Java OS, BlackBerry, Android, GWT(In process), and some others ).
- Multiple WebSocket engines, just switch and run in the configuration, among them (Grizzly-GlassFish, Tomcat, TCP, NIO...) in order to become jWebSocket more widely used and make applications easier to be migrated.
- NFC and SmartCards, Arduino and other technologies.
- A very variated set of Demos in the client side (Games, Chat, sms, WebSocket-Captcha, Sencha, Jquery & jQuery Mobile plugIns, Arduino, Smartcard, SessionStorage, SSH-Remote Shell Control RT in the web, a Ping Pong Game demo, Channels to create full client side applications without need a server side plug-ins, etc... )
We have been working during a long time in a new Documentation, a new Web Site and a new Production release of jWebSocket for our community, jWebSocket is a project created by people from all the world who dedicate their free time to contribute and create a really usable product to be used by all the opensource community. We are trying to give our best to the community.
I wouldn't establish a comparison between Kaazing and jWebSocket, they both have different communities, goals and LICENSES.

For a gaming platform you might want to check out http://www.pubnub.com/. I met their CTO at a developer conference and for your stated purpose, you might just win big with not having to manage the infrastructure on your own. Check out their http://www.pubnub.com/customers/showcase for details on who is using their infrastructure and for what purpose.

For me, the main point is Kaazing has a proprietary license and it's payed. jWebSocket is LGPL and free. If you are developing an application with an ROI that allows you to pay for a service like Kazzing, I think it is a good option (like pubnub.com and pusher.com), but if you want to build a complete solution and host it or you want to contribute with OS community to create a new websocket alternative, jWebSocket is an excellent option.

There are two things I would add to Peter's comment, one is that Kaazing's emulation solution exposes identical APIs to the native WebSocket APIs, so you only have to learn WebSocket not some other proprietary API. You can check out the demos and the doc that Peter referred to for more information.
Secondly, Kaazing just announced the availability of Kaazing WebSocket Gateway AMIs on Amazon EC2 - http://kaazing.com/cloud
Best,
Jonas

I've been working with jWebSockets for the past 3 months or so, and this is the first I hear of Kaazing.
I will describe how I feel about jWebSocket so far to the best of my ability in the hope that it will help.
Setting up the developing environment and getting started wasn't easy but developing using it is rather comfortable. The entire system makes sense and it is quite easy to understand. You program with Java on the server side and js on the client using json based tokens, it makes it very easy to send and receive data.
It is however very lacking in support. There are a lot of missing documentation and the support forum is nearly dead. There is payed support from the developers but I've never tried it.
There are a lot of open source demos that you can use to understand and get started. Most of them were working smoothly. Something I cannot say about kaazing after a brief visit to their demo site.
In the few months I've been working with jWebSocket I've yet to encounter a single bug, The system works smoothly and my only disappointment is the lack of support and documentation.

If you are looking for a pure open source project, look at the Atmosphere Framework. License is Apache 2.
-- Jeanfrancois (creator of Atmosphere)

jWebSocket is a good framework and support almost all servers. It has support of jetty too. Only problem with jWebSocket is slow development and zero support. Websocket specification are changing very rapidly and jWebSocket releases are very slow. I would prefer to wait and watch jWebSocket framework for some time.

Server-side Java dev on Windows

I'm carrying out a feasibility study on writing, let's say it's a lightweight run-in-browser MMORPG. (It's not exactly an MMORPG, but would take longer to explain, and the requirements are similar.) I'm trying to figure out the required technology stack.
Client side, it runs in the browser, so the client is Javascript. That was nice and easy :-)
Server side, I'm looking at Java. The common Lamp stack was designed for RESTful applications, as I gather were typical Java web frameworks, and this application is different - it needs a continual stream of data going back and forth between the server and all the clients. I think what I need in this case is Java of the non-framework, full no-holds-barred Java EE variety, someone please correct me if my understanding is incorrect or incomplete? I would need something that is commonly available on reasonably cheap hosting, Java EE fits this description, right?
(Figuring on using MySQL for the database, as this is what's most commonly available. Also I might actually write the code in Scala, being a Java-compatible but supposedly slightly nicer language. I assume neither of these makes any difference?)
Supposing I were writing a website in Lamp, doing at least the initial development on Windows, then I'd install Xamp, which gives you a running copy of the entire server stack right there on your desktop, so you can just alt-tab back and forth between your editor/IDE and browser for testing.
Now my question is: What's the best equivalent setup for Java, for developing something like this on Windows?

Right, in a sense it is. What I think I'm really saying is that almost all discussion of server-side Java seems to talk about JSP, EJB, Glassfish, Google app server etc which are frameworks in the sense that they put restrictions on what your code can do, whereas Java EE puts no such restrictions, you can use as much or as little of the standard library as you want, but it doesn't stop you running arbitrary persistent Java code. Is that correct?
You've thrown out a bunch of terms there:
Glassfish is an application server that implements (all of) Java EE.
JSP is a specification that is part of Java EE, and implemented by application servers such as Glassfish as well as web servers such as Tomcat and (I think) Jetty.
EJB is another specifications that are part of Java EE. It is typically implemented by application servers.
"Google app server" is really "Google Application Engine" (GAE), and is really a platform for implementing web servers in a cloud computing environment. If that's not what you want / need to do, GAE is probably a blind alley for you.
Glassfish, JBoss, Tomcat, Jetty and so on are all platforms that implement some or all of Java EE. None of them stop you implementing arbitrary persistent Java code.
GAE on the other hand does restrict what you can run, because the platform only allows you to run standard Java classes in a whitelist. If your "arbitrary" code depends on other standard Java classes, you are out of luck. (And hence my warning about blind alleys.)
And of course, there are various other Java-based frameworks that are targeted at web development in one form or another. Some are compatible with Java EE servlets and other EE technology, and some have gone off in a different direction.
My recommendation would be to start with something straight forward using plain servlets on a stock platform. Only look at the high performance stuff if and when performance looks like it will be a real concern (not just a "nice to have"). It is better to have a simple and non-scalable prototype, than a high performance solution that you don't have the time and skills to get working. And you can treat the prototype as a learning exercise.

A little hard to tell from the requirements given, but I would look at the following based on your description:
http://www.playframework.org/
http://www.zkoss.org/
http://code.google.com/webtoolkit/
Play Framework is a nice web-centric framework that provides a complete stack (you can code in Java or Scala). ZKoss (ZK) and GWT both provide user interface frameworks. ZK, GWT, and Play all run nicely in Tomcat/MySQL and should work just fine in typical Java/MySQL hosting environment.

... not sure what your definition of 'cheap' is but, that and 'no holds barred Java EE' don't exactly go together. Also, 'frameworks' by themselves don't put restrictions on running any arbitrary java on the server side. When I say 'frameworks' I mean Spring, Struts, etc. Servers will be a little different story. If you need EJBs you'll need Glasfish or JBoss or another EJB compliant container. Hosting with these will be more expensive compared to getting by with Tomcat. IMHO easiest and quickest way to get started is with NetBeans. Comes with Tomcat and / or Glassfish out of the box, all you need is a db.

What may be the difficulties, if any, with the web applications developed in Java EE?

I have a few questions to understand better Java's usage in context of web applications:-
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
Thank you

Generally the answer to the question of "what technology to use" is "the one which you have most experience with". However, Java EE is huge and clunky, and definitely not good for rapid prototyping, which you will be doing if you're doing a startup.
Personally I would recommend a more modern and dynamic environment. If you're coming from PHP, you should be able to pick up Ruby on Rails or Django (Python) easily. These two choices are in my opinion orders of magnitude better than Java EE. If you want to stick with Java, at least go with the Play framework then.

Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
Yes, I worked in a startup where I was the only full time programmer.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
The same as in any other web development shop. Of course, the problems have their Java flavor. For instance, one bug we discovered was caused by different minor version of JDK used on the live system than on our test system.
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ? Do not code the PHP way. Java's strength is OOP and its many libraries/ open source frameworks. Use that.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I don't know why you think that, but Java is used everywhere. It is one of the few languages that Google officially uses. They use PHP as well, but it has a "lower" status.
and Finally, What are some of the most important things to learn before starting web development in Java EE ? Use Java's strong points which I mentioned above.
Updated after comment
I cannot make the choice for you. If you are in doubt and in a big hurry you should not go with Java. This is common sense. However, it is an opportunity for your team to learn and grow. Maybe there is a PHP/other client for Cassandra. I knew a former PHP programmer in a startup, who switched to Java. Not saying anything bad about PHP programmers in general, but he did all kinds of strange things, such as not leveraging the power of Java web frameworks and writing lots of procedural code mixed with HTML and SQL. Obviously there are lots of Java programmers who would do the same thing. The point is that your team will probably learn new ways to do things and benefit from it in the future.

Allow me to answer these from the perspectives of a developer/architect in a small start-up, experiencing a bunch of these issues.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
How do you decide on which toolset/framework to use? Do you need an IDE? Which version control system and why? Do you want to develop at some place and deploy somewhere else, or develop directly on the server? Do you buy a linux box for this, or rent some cloud? How much do they cost, in terms of licenses and training?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
How would your servlet send out an e-mail? It's much simpler in PHP. Need secure transfer of encrypted objects? Java is your friend. What about session tracking? Use cookies, or have a dedicated class do it? How do you access the database? Want to use hibernate? What other tools is hibernate dependent on? What are their costs (license+learning)? Can you use JDBC directly? What are the pros and cons? Which db to use to why.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I am not sure if this is the case, but possible reasons could be the availability of .net and integration with C# based systems and Apple ditching Java from its SDK. But that is my speculation, don't quote me on it. I am developing a large scale system myself with Java 6.
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
(This is my opinion) have a test or trial set up of the entire architecture. Is the GUI web-brower based? Is it an applet? Standalone application talking to a server? JNLP system downloading archives and JRE off the net? You will find some stuff do not work on Windows 7, some do not on Vista, W3C have deprecated the applet tag from HTML but Sun/Oracle asks you to use it, different browsers do not support contents of your style sheet, etc.
Firewall set up is another major challenge - you start using thread pooling using Spring libraries and your capabilities to use DBvisualizer to check on DB tables are gone! Now you need a DBA and a sys-admin to fix these who you do not have!
Personally I found the LAMP architecture (Linux-Apache-MySQL-PHP) the fastest way to go for smaller applications, but if you need heavier guns for your app (security, GUI with swing, multithreading, etc), replace the P in LAMP with a tomcat container. The hardest thing I find is to judge the value of a tool in the context of my application - I do not need a tool that generates Java files with getter/setter methods given a list of variables - to me that is yet another level of indirection, but then JUnit in eclipse is helpful for debugging.
Just shared some of my thoughts - hope this helps, - M.S.

For a startup an interesting choice could be the Lift web framework, which is used for developing "Java Web Applications" (although in Scala).

How do you go on about learning enterprise Java application servers?

Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?

Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.

I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.

From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.

I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.