Newbie question about Java

Question

Okay, I know that Java is a language but somebody has asked me if they can write a web application to interface in with a web app I've written in ASP.NET. I'm implementing a web service to serve up an XML so it's pretty language agnostic.

However, I'm not 100% sure whether going down the Java route makes a lot of sense. I was kind of expecting PHP or ASP.NET server side code with maybe some Ajax/JavaScript or maybe a heavier client JavaScript program using JScript.

Could some kind sole explain the basic Java environment when it comes with webapps. I've inferred the following - am I barking up the right tree?

• Java when run like ASP.NET is called JSP
• JavaBeans is a bit like the .NET framework, i.e. it's a library of re-usable components
• Java EE is a bit like ASP.NET in that it's a framework for building web pages on a server
• Java can also run on the client but it needs the Java VM installing

When running Java on the client, can you use JavaBeans and is there a framework? Can it also use JScript? I don't think so as JScript is JavaScript library.

Whilst running Java on the server would be okay, this is a relatively small application and therefore Java sounds like a bit of overkill. PHP or ASP.NET feels a better fit.

But I don't think they should go down the Java applet in the browser and it adds complexity that's not needed.

Thanks, Rob.

Answer 1

Let's try to define some terms (not necessarily 100% exact, but understandable)

• Java: can be a lot of things: The language, the JVM, the platform, the idea, ...
• Java SE / JSE: Java Standard Edition: "normal" Java as it is used to run desktop applications. This has formerly been known as "Java 2 SE" and "J2SE".
• Java EE /JEE : Java Enterprise Edition. The enterprise-level stack for developing web applications and other more complex beasts (contains tons of components). This has formerly been known as "Java 2 EE" and "J2EE".
• JSP: Java Server Pages. A language that allows mixing HTML/XML content with Java Scriptlets. Pretty much equivalent to ASP.NET.
• Java Beans (note: not "JavaBeans"): a rather light-weight specification that just describes how classes should be written so that their properties and methods can be automatically discovered. Not to be confused with Enterprise Java Beans (EJB)
• Enterprise Java Beans / EJB: The much, much more complex bigger brother of Java Beans. Allows you to encapsulate some parts of your application. Terribly complex and cumbersome to use (got a bit better in recent versions, but that change seems to have come to late).

JScript is the Microsoft dialect of JavaScript and has nothing at all to do with Java.

By the way, JavaScript doesn't have anything to do with Java either. The only similarities are the first 4 characters of their name and a superficial similarity in syntax.

So basically: if they want to write a Java application to interface with your application that simply provides some XML, then Java is definitely suited for this. You don't need any of the Java EE technologies for this. Java SE is more than enough for this.

Edit: Note that it is a fairly common practice to not use the entire Java EE stack for (small-ish) web applications. Specifically Apache Tomcat, which is widely-used, is not a full Java EE Server (as required by the Java EE specification), but rather an implementation of the JSP and Servlet standards (two core parts of Java EE). It still runs many, many useful Java web applications just fine, because they simply don't use the more complex features of Java EE.

Answer 2

Sounds like you've got a good handle on things.

You are correct to hesitate using J2EE for a small web application. I found this .NET/J2EE feature comparison helpful. Note especially the second chart's comparison of costs and complexity on a test project developed by Microsoft and Sun.

Java offers tremendous power, but is better suited for large web applications. I would tend to agree with your preference for ASP/.NET in this case.

Answer 3

That seems a pretty good overview of the landscape.

I agree with your evaluation of the applet approach, good if you need really complex processing at client. Otherwise HTML augmented with JavaScript is just fine, some work to make it portable across browsers though.

The server side aspects are moe intersting. If the person consuming your Web Service is already Java-fluent and perhaps already has the Web App infrastructure in place there's no reason to be concerned about the use of Java.

So if they are writing it, just let them do it.

On the other hand you a .Net programmer are being asked to skill up in Java I think that's non-obvious (and I'm Java to my Blue core) If I wanted a quick and easy approach to doing a web site in a green field situation I'd use something like php or Smash

The advantage of Java in a JE sense or, I assume, a full-blown .Net approach is that you get a scalable, cluserable, administerable (is that a word?) solution. Just because the function is small and easy don't assume it will not be heavily used.

Answer 4

Java when run like ASP.NET is called JSP

This is sort of true - a traditional JSP page is a lot like a classic ASP page. There's no "codebehind" like you have with ASPX.

The big difference in Java is that the web framework is based around things called servlets. A servlet is a bit like a ASP.NET "axd" in that it handles raw HTTP requests (get, post, etc) and spits out a response.

On top of that servlet "base" are many other frameworks - JSP is one of them (JSPs are ultimately compiled by the server into servelets). JSF, Struts, Tapestry, and many others are also built on this base. In the .NET world you really have two choices - ASP.NET (.aspx pages with codebehind) or .NET MVC. Most of the Java web frameworks are more like .NET MVC, although (as I understand it) JSF is more like ASP.NET

JavaBeans is a bit like the .NET framework, i.e. it's a library of re-usable components

Not really. What you are thinking of is J2SE, which is the basic framework upon which all Java apps are built - has the collection classes, sockets, security, etc. etc. JavaBeans is just a specification for how to write DTO type objects (standard naming for getters and setters, etc.)

Java EE is a bit like ASP.NET in that it's a framework for building web pages on a server

This is more-or-less correct. J2EE is an extension of J2SE for doing web development (as well as EJB's which are a whole nother ball of wax that don't really have a direct equivilent in .NET)

Java can also run on the client but it needs the Java VM installing

Yes, this is true. Just like you can use .NET to develop desktop or web applications, you can use Java the same way. And in both cases, a runtime is required (whether thats the Java VM or the .NET framework)

As for your assessment about using Java vs. PHP vs. .NET, I've worked with all of them, and I would say Java is the most complex, but also very powerful for very large scale applications. PHP will be the easiest by far, and is great for small apps, but can get messy when things get bigger. ASP.NET has a pretty good balance. Quite a bit more complex than PHP, but also much more powerful.

Answer 5

It's not entirely clear to me if you are writing the webservice or it's already written and someone just wants to use it?

If they just want to call your webservice it's language agnostic so it shouldn't matter what language/libraries they use.

If you are writing the webservice, again, it really doesn't matter which language you use, just pick one you are comfortable with and has a nice library.

If you decide to use Java I have experience with Axis2 and it's quiet simple once you get your head around what it's doing. You can write a POJO (Plain Old Java Object) and tell Axis that's what you want to expose. Load it up onto Tomcat or something similar and you are good to go.

Answer 6

The short answer -- to the question you didn't ask :) -- is: Java should work fine. If Java's what your client / partner / whatever is most comfortable using, let them* use it.

Specifically:

• If you've written an ordinary SOAP web service with WSDL, a Java app shouldn't have any trouble talking to it. I've written Java clients that talk to .NET web services and .NET clients that talk to Java web services and while there's always a little bit of fiddling involved, there's no serious hassle unless the services are sending embedded binary objects around or something else non-standard like that.

• If you've just written something that serves raw XML over HTTP, Java shouldn't have any more trouble with that than .NET would.

Java isn't necessarily any more heavyweight than PHP or ASP.NET, if you use a lightweight server like Jetty. No browser applets need be involved. And Java has solid, stable libraries for talking to web services. (PHP does, too, but I'd be surprised if the Java ones haven't been much more heavily exercised.)

For your other questions, wou might want to have a look at the Wikipedia article ".NET framework: .NET vs. Java and J2EE."

---

* If they want you to write their end of the web service, that's a whole different ball game. Possibly they have some existing Java infrastructure they really, really need to reuse -- in which case I'd suggest picking up a good basic book like O'Reilly's Head First Servlets and JSP -- but otherwise, if .NET is your expertise, that's what they should be letting you use. If they don't like Microsoft, tell them you'll make it run under Mono.

Answer 7

Does it really have to be Java? Perhaps you could write a small web app using JRuby or Groovy that consumes your ASP.NET web service. There are tools (.ie. Apache CFX) in JRuby, Groovy and plain old java that lets you consume your WSDL to create clients on the fly.

Having said that, it's hard to give a good suggestion without knowing exactly how this Java client is meant to be used. Is it going to interface with actual users, or is it like a batch job?

If it is the later, you can knock that out quickly with Java or JRuby/Groovy. Since the later technologies can be compiled into jars, they can run on the JVM.

If it is going to be facing users, then you have to either create a web client or a thick client.

For the former, you could go the JRuby/Groovy route and create a small web app, which you can deploy on a stripped down Jetty/GlassFish/Tomcat app server. Or you could go the Java way and use one of the many frameworks.

Independently of JVM language choice, it is a lot simpler to create a web app than a thick client. Creating a non-trivial GUI client with Java with good UI design is no trivial task unfortunately. I've work with both web and thick clients, and that's been my experience (YMMV).

I would not be too worried in thinking about the overhead of using a web container. You can run a lean-and-mean web app in a container in about 500mg (which should be a drop in the water for a server.)

And if you really stick to plain servlets and no JSP (that is, the servlet creates the HTML output) you can use a really mean and lean and tiny servlet container like TJWS, LWS or Winstone which can run with less than 1MB.

Hope it helps.