I am currently developing an application for some researchers in my university.It's a small java program that you can use by command line. The next step is to package that program and deploy it to an application server. Some clients program will submit requests to the server who will call the tool that I wrote. Lately, we will add more tools to the server and he has to dispatch the requests to the right tool.
Which application server fits my needs ? I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Is it possible to use those servers in some context different from web context? Which package archive should i use (jar, war) ?
Any advice?
Some clients program will submit requests to the server who will call the tool that I wrote.
The big question is what server-side technology and what communication protocol can you use between the clients and the server. You basically have two major options: HTTP and web services (in that case, consider using either JAX-WS or JAX-RS) or RMI-IIOP and EJBs (in that case, you'll have to use a Java EE compliant server like GlassFish).
I have looked for Tomcat, Jetty and Glassfish but it seems that they are only used for web application.
Not really. As I said, they can also be used for web services oriented applications. And GlassFish can be used for EJBs applications.
Which package archive should i use (jar, war)
The packaging will depend on the type of application you'll write, it's not something that you choose upfront, it's just a consequence. EJBs are packaged in an EJB JAR and typically deployed inside an EAR; Servlet based web services are deployed inside a WAR.
You really need to think about what technology to use first (with the current level of detail, I can't provide more guidance).
Do you even need an application server? There's nothing stopping you from adding the necessary network bindings and deploying it on its own.
Of the servers you mention, you've got 2 different categories: servlet containers and full-stack Java EE servers
Tomcat and Jetty are servlet containers. That doesn't mean that you can only do web stuff with them and you could manually add the required libraries to get a full Java EE server.
Glassfish is a full-stack Java EE server and can be compared with JBoss (both are open source) or the commercial rivals Weblogic and Websphere.
Sometimes this question is simple as the environment you are working in mandates a particular flavour of app server. You should check this first.
If you're not forced to use an app server, I'd ask why you think you need to use an app server?
I don't see why you would want to use tomcat, glassfish or jetty for a command line program.
If it's command-line based, and you want it to run server-side, you could write a little program that allows users to, for instance, telnet to your server, which in turn starts the CLI-application in question, and relays input / output to the client.
You may also want to look into Java Webstart, which makes deployment of new versions a breeze.
Actually we can't answer with so few elements.
- What are you planning to do
- With what technologies
- Where are you planning to host your application (have you got budget?)
- In which language are written the clients (even the future ones)?
- Could clients be on mobile phones (add some technlogy constraints...)
....
It would also be great to know what kind of request the clients will do, and what kind of response the server will provide...
Actually with what you tell us, all those application servers can do what you want...
I have looked for Tomcat, Jetty and
Glassfish but it seems that they are
only used for web application
You could even make a webapplication (servlet) and on the clientside use a httpclient to call that servlet... there are so many options :)
vive Paris!
Related
I have a stand alone Java application that needs to get information (string data) from a Java EE application, running on a Glassfish 3.1 Application server. I have created a web service for my Java app, but I'm wondering how I could achieve communication with the Java EE glass fish app (using servlet?).
I hope to have a method on my app that can be called from, for example, a client running on glassfish (and vice-versa). This method would have something like a String array as parameter, so that I would be able to pass the data between the apps.
Note: I am unable to deploy my app on Glassfish, since we are trying to achieve separation till we are sure the application I am developing will not cause Glassfish to crash ( we currently have other critical apps running on Glassfish). Also note that this is all taking place on the same machine.
You should develop a web service and deploy it on Glassfish within your existing application. You can do this via a Servlet based web service, or a Session Bean web service, whichever is more appropriate for you.
You will then create a web service client against that web service for your Java app, and integrate it appropriately with calls to the servers via the web service.
Of course, this should all be done against development servers, not your production servers. Glassfish can be deployed pretty much anywhere: your machine, another machine, a VM, in "the cloud". Not having a development server available for, well, development is unacceptable. There is no way you can determine if your app will "crash Glassfish" unless you can test it.
To quote the esteemed Donald Knuth: "I have only proved it correct, not tried it."
Get a test server, develop against it. Move forward.
Have you looked at the URL class.
try this url Java URL example
This may help
I have an existing Java application running on a linux box that monitors the state of relays and network information. This is a stand-alone device currently.
What I would like to further develop is a web server for the device to remotely monitor, configure, and control the device via an Ethernet connection. To achieve this, I need some way to interface between the web server, which could be configured as enabled/disabled, and the master device, which is always running.
Is there a good way to do this? I have looked at apache w/ tomcat and similar web servers but not sure if this is what I need. The key here is that the web server needs to be able to access the existing java application without interfering with its always running services.
You either develop a webapp, use your Java application's API inside the webapp, and deploy this webapp inside a web container. Or you can do the reverse and embed a web server inside your application (see here for documentation to embed Jetty).
If you want to keep the webapp and the original application in two separate JVMs, you'll need some wey to communicate between both, like sockets, RMI, or even files, but it will be more complex.
You might want to take a look at JMX http://docs.oracle.com/javase/tutorial/jmx/overview/index.html
We have a java server application which runs certain batch jobs. It's core function is not as a web application and there's no reason for it to be that. But we would like to add an option to check what the app is doing from a web page. And we thought this could be nicely done with the Google Web Toolkit.
In any previous experiences we have with GWT we have deployed it on Tomcat. But in this case it seems like overkill. The web part is more of a side function to what the application is actually doing.
I'm thinking of a solution where the web server is integrated into the jar file - perhaps Jetty? So that the full java application can be deployed to a single jar file together with the web/GWT part.
There may be performance aspects to this but the web side of things will have very few users. Are there any other reasons not to do it this way?
And, can you give some advice on how to configure Eclipse / Ant / Jetty / GWT for this?
we had the similar experience at our previous project. There was an eclipse-rcp application, with embedded Jetty server (it was started programmatically when application was starting). GWT application was deployed into the Jetty as usually. Also there was a OSGI-service as a controller to provide communication between GWT-server and other parts of application. GWT server was usual RCP server, which is described in the most of examples. It had a reference to the controller. Moreover, it was an event listener, to support bot-side communication.
The main problem for us I think, was synchronization problem. Since there were a lot of messages between eclipse-rcp application an GWT-part (every let say 100 ms the message was received) and GWT had an asynchronous way of communication between client part and its server part, then some mechanism had to be created to synchronize those messages. Otherwise there were no performance problems (except IE 6. which had to be supported:S :D).
Hope this will somehow help.
Upd: As far as I remember, the controller was registered as OSGI service only to be able to communicate with other services of Eclipse-RCP part. In order to communicate with GWT controller was implementing special interface, which was known to the GWT-server (Controller was registered as an implementer through instantiation and the server was regsitered in the controller as IMessageListener). This interface was lying in separate project, which could was also built into the .war file. This project also contained number of event to support backward communication from controller to GWT-server through IMessageListener interface.
It's kind of confusing probably, sorry. May be I should draw a diagram..
I have a standalone java application which uses java based TCP NIO to collect some information from various clients (not on web/HTTP but through some indigenously developed middleware). Now I have to develop a front-end for the users to perform a lot of querying through HTTP. So is there a way to put this application inside tomcat, so that servlets can invoke required functions on this application ???
The thing is it has to listen on that middleware outside tomcat too and at the same time service servlets inside tomcat. How to do this ??
Putting this application outside tomcat and using RMI is an option but I don’t want to do that.
Can embedding tomcat inside my application is an option ???
The brand-new Tomcat 7 has Embedded version for download.
Tomcat is big. You should try to embed Jetty, which is meant in order to make it possible.
http://jetty.codehaus.org/jetty/
I don't know about embedding Tomcat, but you can embed a servlet container inside your application using embedded Jetty. If what you want is to add an HTTP interface to an existing server, I think that's the way to go.
It also should be perfectly workable to launch your server's TCP listening components from a standard servlet in Tomcat. Then the servlet can call methods in your existing application directly, while it continues to listen to its usual TCP ports.
A third option is to write a servlet that just talks to your existing server in the same way other clients do.
The way you want to go, is to have an embedded web server to your existing application since you just need a little bit of web functionality.
Going the other way is possible. You can use servlet listeners to get started and stopped, and you need to take great care of any thread you start since Tomcat have no idea they exist.
As Traroth said, embedding Jetty is a much better option than doing the same with Tomcat. You have an example and a small tutorial in the Jetty website:
http://docs.codehaus.org/display/JETTY/Embedding+Jetty
You can always open the ports and listen manually if the requests aren't complicated.
Have you considered going the other way? That is embedding your application inside a web application?
Using spring you can instantiate your web application and then inject in into the appropriate web classes (e.g. struts2 actions).
This way you can deploy your web application into any web server that is preconfigured separate from your application.
If you do have to use Tomcat, you're best just making your application as a .war file which when Tomcat is ran will deploy your code. This can then talk to any RMI/middleware you like.
I'm not sure I understand your comment regarding memory spaces.
At a very basic level you have two choices:
Run your appication and the web
application in the same virtual
machine.
Run your application and
the web application in a different
virtual machine
If you take approach 1, you will be able to get instances of your applications classes from the servlets and call methods on them.
Embed tomcat / jetty inside your application. You will start your application normally through its main method. After starting your app you will need to create instances of the tomcat / jetty classes which will start up their own threads.
Embed your application inside a war file to be deployed on tomcat / jetty. Similar to the previous option instead you will need to start your application from a context listener.
If you prefer approach 2; start tomcat / jetty and deploy your web app and separately deploy your application. You'll now have two jvms running. To communicate between these two processes you'll have to use some form of socket communication: OutputStream/InputStream over sockets; RMI; JMX; JMS etc.
As the title suggests, this is in relation to Java EE and Glassfish in particular.
From what i've learned the application client is executed in some application client that has the ability to talk to glassfish. But there seems to be limitations to this regarding annotations.
Can someone give me an example of the difference in connecting to a glassfish application server from the two different application types?
What is the benefit of the application client approach, and what approach is the most commonly used when developing application clients for Java EE?
The code (work you need to do) associated with connecting to the app server in either case is not really all that hard... but it is covered in different docs.
These are the instructions on how to access an EJB from a stand-alone java application.
These are the instructions for using an app client to access an EJB from a Java EE 6 Application Client with GlassFish v3: http://docs.sun.com/app/docs/doc/820-7695/beakt?l=en&a=view
Accessing an EJB from an application client gives you access to more of Java EE services 'automagically' than if you were working with the EJB 'directly'. You can cobble together access to some of these services in the stand-alone case, but the burden shifts onto the application developer/deployer to make that access work.
Creating a stand-alone application that accesses an EJB will seem easy, in the short term, and many folks will invest in that strategy. If they deploy their client application onto a large number of machines, the burden associated with a cobbled together service access strategy can become a burden.
Deploying an application client that uses the application client container is not free either. The advantage is the fact that you have the support of your app server vendor to overcome deployment issues.
If you are using GlassFish (v2.1,v2.1.1 or v3), you can also take advantage of Java Web Start support, which simplifies client application deployment a lot.
An application client is actually run in a container and has full access to Java EE resources defined on your server in the same way that a Servlet or EJB does. This would typically be used for some type of admin client, not a user application. Here is one explanation.
In addition to the Java EE Application Client, there is also the concept of a Thin Client, which allows access to some Java EE resources as well, but not as easily as the App Client. It usually involves using JNDI lookup with absolute names as JNDI references are not available. A typical case for this would be a standalone producer/consumer of JMS messages. It is basically a lighter weight option of the full App Client.
If you are simply creating a user application, you will most likely want to either use a Thin Client model, or a plain old application that simply consumes services from your Java EE app via servlet or web service calls.