We're running a Wildfly Server with an Java EE application that uses Hibernate. Now we need to implement a Java SE client that get some data from the database that Wildfly is using. What's the best practise for doing that? Using something like RPC? Or JAX-RS Client? The database itself is not accessible within the client. Thanks for helping!
It very much depends on how your server app is working and whether you have access to it's source code and ability to change it in case it doesn't have any web service implemented inside.
If your server app already does have any endpoints, the best choice would be to use those.
In case it doesn't have any endpoints at all, the most usual solution would be create JAX-RS web service on server application and use it in your Java SE client application.
Related
We want to develop a Java based Web-services (since the API's we want to use are Java based)
I would like to know if it's possible to use the IBM Rational Team Concert Plain Java API's (https://jazz.net/downloads/rational-team-concert/releases/5.0/RTC-Client-plainJavaLib-5.0.zip) as part of the Web-servicesand deploy them in the server?
Basically we use these API's on a client based Java applications. What I am looking at is more like a services which can be consumed by many applications
Anyone has any experience in deploying the client based API in the server as Web-services?
After multiple tries, it is possible to use the RTC Plain Java API's as Webservices.
How I did:
Followed the simple Webs Service creation tutorial (http://wiki.eclipse.org/Creating_a_Bottom-Up_Java_Web_Service)
Adapted to my needs
First added the "RTC plain Java API's (JAR's)" to the Eclipse build path
Then added the "RTC plain Java API's (JAR's)" to the "WebContent/Lib/" folder of my Dynamic web project
Created a new Web service & Web service client
I was able to login to RTC via this for starters
I've read some articles on the Internet that this is not possible. To communicate own SQL database that is located on other server from GWT application. Jetty doesn't allow it.
I found a way how to perform it but it's not very cosy. I have client and server part inside GWT. The server has to communicate with MySQL database on localhost. So I've written an ant script to build a war that I can launch on Apache Tomcat server. It works perfectly there but I'm not able to debug the code effectively.
Do you have some advices how to perform this task? I was thinking of writing the clienty only in GWT and find some waz how to communicate my own server written outside the GWT. I've found Apache Thrift for GWT but this edited library of thrift seem not to work properly.
Thank you very much for your answers:)
It is possible to communicate with a database from a GWT application. The client side has to call the methods of the server via GWT-RPC, which can communicate with any database.
Maybe Jetty does not support it (have not tested it personally) but you can develop your web application using Apache too. There you can access the database the same way as from any web application:
You will need the mysql-connector-java-5.1.20-bin.jar file (downloadable from: http://dev.mysql.com/downloads/connector/j/ ), and restart the server added to the $CATALINA_HOME/common/lib directory.
OR added to the WEB-INF/lib folder of your web application.
You can find tutorials online of how to develop an application using Tomcat instead of Jetty. For example: https://wiki.auckland.ac.nz/display/BeSTGRID/Deploying+GWT+to+Tomcat+in+Eclipse
Reshi, stop and think about how applications really work. Nobody provides web pages with javascript to read/write databases, that would be crazy and unsecure. Servers are always in themiddle of all communication in this case. You need to create services that run inside your server, one of these services will be a database layer.
Javascript cant create network connections and read/write binary data, thus it would be insane to attempt to get the gwt compiler to compile any jdbc drvier and more.
Jetty does NOT stop us from connecting to a database. All you have to do is to follow the MVP model way. Although MVP is better bet against all hurdles, at a minimal point, you would have to try not having SQL code on the client package.
I've made a Google Web Application Project in Eclipse and am now running into problems as I need to use from a server side point of view, with Hibernate with MySQL. I've just been told that Google Web Application projects can't run Hibernate connections to MySQL as they're deployed projects.
What's the best way for me to migrate this project somehow so it runs on say Glassfish and just uses GWT for the client side technologies that can then use Hibernate and MySQL, rather than actually being deployed?
Thanks,
David
You cannot access database from client-side directly.
GWT translates your client-side java code into Javascript which runs in browser; there is no way to directly access JDBC.
You will have to employ server-side which will handle your DB persistence. Your client can communicate via GWT-RPC, JSON, XML, or any other protocol - but the database connection part will always reside on server.
Note that the server part does not need to be in Java - it can use PHP or any other technology, as long as it understands the javascript generated out of your app.
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.
I'm tasked with creating a Java Web Service for a .NET 2.0 client to consume.
What would your suggestions for the implementation be?
The solution doesn't need to be very heavyweight (don't need a full Java EE container I believe) but what do you think is the best solution for this? I have thought about using Glassfish v2 with JAX-WS annotations (#WebService), and JAXB XML Bindings(e.g. #XmlElement), which I assume the .NET client would be able to consume?
Has anyone tried this scenario?
Would Glassfish be overkill though, since I'm merely using the Web Service as a mechanism for .NET on Windows to communicate to the Linux box, the underlying application is extremely small.
Any suggestions are more than welcome :)
Thanks,
James
P.S. Other notes - would you use Axis/CXF instead of Glassfish? Would you use a servlet container such as Tomcat? etc.
I have used Axis2 and it works.
I had the same problem of making Data Exposing API (Web Service in my case) in Java.
I made the web service using Axis2 and Spring (to access database) and the WSDL created via Axis2 was easily consumed via ASP.NET Application via its Add Web Service Dialog Box and the corresponding Proxy Classes were created easily.