I have a standalone java application that initializes and establishes socket connections, both server and client. The standalone java application have operations such as startConnection, stopConnection, getConnectionStatus, etc.
I would like to develop EJB to access or invoke the standalone java application operations, such as getConnectionStatus. The EJB will be deployed to Glassfish.
If the EJB can access the java application and receive results, would you provide an example, references, and/or implementation strategies?
I am not quite sure what you are trying to do.
You can either create some EJB(s) and include the classes that your application uses in your .jar file, or package that application's jar into your EJB's (.ear or .war) file (depending on how you are deploying). This would statically link the code which runs with a "standalone" application with your EJB(s).
Alternatively, you can add some remote invocation methods to your standalone application and turn it into a server that can accept commands. To do that, you can look at Hessian which can allow you to remote services in your application. Here is one example that I found: https://karussell.wordpress.com/2009/04/10/hessian-web-service-protocol-hello-world-example/
Related
I want to run a standalone java application on a remote server. It would not be accessible to clients, but would do background calculations and interact with a database and Secure Socket connection to a third party site. It would also interact with a php site.
Do I have to deploy this with JSP, or can I write a standalone application? If so, how would I deploy a standalone java application (jar file) on a remote server? I understand that I must have them install a jvm on the server (not a problem) but then how would I deploy it (if possible). Would I start it with a command line?
I know I have much to learn, but I am not sure how I would access the command line on a remote server. Through the cPanel?
Thanks.
First of all, you'll want to set up some firewall rules to allow access to that server. I'm hoping that you don't expose that server naked to the Internet.
If all you need is database access exposed on the Internet, I don't see why it can't be a secured web app deployed on a servlet/JSP engine and accessed via a web server. You can leverage basic auth for security, JDBC access to the database from the server, and servlets as controllers to accept requests in a nice REST API.
It'll save you the complications of sockets and inventing your own protocol (use HTTP), starting and stopping the application (now it's just a web server/servlet engine), and deployment (send a WAR file).
Does it really must be a 'standalone' application? I think that in your case the best match would be to use Spring container to load your application within some server (tomcat?) and expose services via standard controllers - with Spring you only have to add some annotations on services methods actually.
Then, your php site can interact with these controllers using for example ajax requests.
If your application is written already, you can easily transform it to run within Spring container. It's very non-invasive and promotes usage of POJOs.
I need to create EJB and a plain java program(client) in different JVMs and get them executed. How should I do this using NETBeans IDE in my system.
It seems to me that you are looking for a Java EE Application Client.
Basically you have your Java EE container, where your EJBs live, running in one JRE instance (your Application Server Java process) and you need a standalone java application to be able to communicate with your EJBs.
Creating the Java EE Application Client
You will need to create the EJB firstly, plenty of examples around for that, but basically create an interface with (#Remote) and an implementation bean (#Stateless for eg.)
Then you will need an Application server to deploy or test the EJB, you can use NetBeans to start a debuggable instance of an Integrated Enterprise Application Server (Like JBOSS), plenty of examples around of those too, once that is done, you can simply create a test class (in NetBeans and do a remote jndi lookup (to localhost) in your test class) Your instance of the Appliction server will run another JVM, and your test class (should probably have a main method, or create a junit test, even better to test it :-)) will run in it's own JVM.
So you need an EJB (packaged and deployed (can do through Netbeans)), an Application Server (to deploy the EJB), running in an instance (Netbeans or stand alone)
And the test class that will perform the remote lookup and invoke any of your EJB"s methods.
This you can all do from your "system" - localhost.
NetBeans already starts different applications in different JVM processes (java.exe).
You just need to deploy your ejb-jars in different server instances (which are containers for your EJBs).
Also, if you deploy your jars in different EAR's in the same server (other than JBoss) they will be loaded by different classloaders, meaning they won't be able to interact very well.
I have two java projects. From project1 I have to call a method of project2. Both the projects are developed using the core java concepts and running seperately. As I know that in this case I will have to use any techniques that remotely invokes the methods(Am I correct?), like RMI, WebServices, JMS etc. I have to very frequently call the method of project2 from project1. What could be the best possible way to achieve this.
Thanks
Are your projects deployed to an application server or servlet container?
You can use web services to expose the method from Project 2. This would be standards based and would allow non-Java projects also in the future to access your service if required.
If it works for you, try to implement it in an asynchronous mode for better performance. Web services allow for asynchronous mode of invocation as well. However, for this, your Project 1 would also need expose a callback method.
EDIT:
I had come across that in Java 6, you can deploy web services outside of servlet container as well. Below link can help.
Standalone web services in Java SE 6
However not sure if this can be used in production environments.
RMI is used in Client-Server architecture. There will be a server program that will implement your interface extending Remote and it will have definitions or calls to other methods at server and it will bind an object. Then you will need a client program that will look up for that object and using that object, it will call methods on Server.
So if your projects are running as Client-Server then you can try this thing.
Next thing you are talking about is WebServices. WebServices provide access to some code written at server to its clients over a network via specific protocols. In this your code will be running on a server and you will access it from your client using Web Service.
Now it is up to you what kind of architecture you are following for your projects and which method is more useful and suitable for your scenerio.
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!
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.