I need to call EJB (created using NETBEANS ide having glassfish server) from a plain java program (without using any IDE). I have been told to create both EJB and client in different JVMs, and then get them executed. (by different JVMs I dont mean different insatnces of a JVM).
Have a look here: http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB
You can use any IDE to create your client application, for testing purposes you would have to move it to another machine and configure it to connect to your running glassfish instance (look into part 4 in the mentioned document)
just as what you do between different JVM instances.
put a interface jar in your class path and lookup ejb instance from JNDI.
Related
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/
Is it possible to create a client that accesses an EJB3 bean, with the client having no dependence on a vendor JAR or configuration? We currently need to support scenarios where our service is deployed on a WebSphere or JBoss server, and the client is deployed as an application either on a WAS or JBoss, or is running as a standalone app.
I used to be able to do to this with EJB2.x beans, I just needed to create stubs using RMIC.
But with EJB3, If I'm connecting to WebSphere I have to include thinclient JARs, plus I have to pre-generate the stubs using WAS tools. For JBoss I have to use jboss-client.jar.
No, this is not possible. This has been made explicit in section 10 of the EJB 3.2 specification:
This chapter describes the interoperability support for accessing an
enterprise bean through the EJB 2.1 remote client view from clients
distributed over a network, and the distributed interoperability
requirements for invocations on enterprise beans from remote clients
that are Java Platform, Enterprise Edition (Java EE) components.
Distributed Interoperability is not defined for the EJB 3.x remote client view.
Also note section 10.5.5:
System value classes are serializable value classes implementing the
javax.ejb.Handle, javax.ejb.HomeHandle, javax.ejb.EJBMetaData,
java.util.Enumeration,java.util.Collection, and java.util.Iterator
interfaces. These value classes are provided by the EJB container
vendor. They must be provided in the form of a JAR file by the
container hosting the referenced bean. For interoperability scenarios,
if a referencing component would use such system value classes at
runtime, the Deployer must ensure that these system value classes
provided by the container hosting the referenced bean are available to
the referencing component. This may be done, for example, by including
these system value classes in the classpath of the referencing
container, or by deploying the system value classes with the
referencing component’s application by providing them to the
deployment tool.
For WebSphere Application Server, the EJB thinclient contains these system value classes as well as the IBM JNDI implementation that uses CosNaming. In theory, this thinclient is not needed if you don't need the system value classes and your client JVM has its own ORB with an implementation of CosNaming.
Short answer: No, it's not possible, as a client needs three things:
The interface classes.
The client libraries of the server AS (yes, sadly)
A configuration telling the client the server address/jndi lookup path (qa, prod etc.)
If your client is running on the same product (let's say JBoss to JBoss communication), you will not be in need of client libraries and just be able to do a remote lookup. If you have a mix of client/server application servers this will make things complicated, as you will have to run client libraries of one product in another server product.
Speaking of standalone applications running as clients, I'd just build and provide 1 heavy client jar/lib containing not only the interface classes, but also the client libs of both servers. Then providing a small helper class that returns the correct InitialContext created and based either on JBoss or Websphere depending on a flag in the client configuration.
I know this last idea ain't a clean solution, though might even work in a different AS product running as "client".
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 understood that Local interface is designed for clients in the same container's JVM instance and remote interface is designed for clients residing outside the EJB container's JVM. How about the web application client which is not reside (or packaged) in the same .ear but reside on the same Java EE server?
Officially #Local annotated beans can only be accessed if they're in the same application. A .war deployed separately from an .ear (or other .war or other .jar EJB) is a different application, even when deployed to the same application server instance.
There's thus no guarantee that the code in your .war can call #Local EJB beans that are defined in the .ear.
However, in practice in nearly all application servers this just works.
There's a request for the EJB 3.2 spec to officially support local cross-application calls: https://download.oracle.com/otndocs/jcp/ejb-3_2-fr-spec
Local interfaces are to be used in communication within the same application. It doesn't necessarily mean JVM.
The point is: even within the same JVM instance, on the same server, two different applications cannot communicate using local interfaces (which means local and no-interface views).
If you have a web component (WAR) as well as a business component (EJB-JAR) which is in the same application, the most intuitive and straightforward solution is to package them in one EAR or in one WAR (since Java EE 6).
You use the remote interfaces, but you make a lookup using JNDI (that's how i'd do it), this way you find the instance of the EJB in the server and can use it in your web application.
Although you still need a jar with the EJB interfaces in the web application project.
EDIT and I agree with JB Nizet, why would you want the WAR outside the EAR?
Remote interfaces can be called across applications, from everywhere within the application server as well as from outside, even from other hosts.
So assume that you need remote (#Remote) interface. In EJB 3.1 you can use dependency injection.
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.