I am planning on building a GWT app that will be deployed to GAE. In addition to the normal (GWT) web client, the server-side code will service requests from other clients besides just the web app. Specifically, it will host a RESTful API that can be hit from any HTTP-compliant client, and it will also service requests from native apps on iOS and Android.
If my understanding of GWT is correct, it's your job to code up both the client-side code (which includes the AJAX requests your app makes back to the server) as well as the server-side request handlers.
This got me thinking: why do I need to package the web client and the web server inside the same WAR? This forces me to (essentially) re-deploy the client-side code every time I want to make a change to the backend. Probably not a big deal, but if I don't have to, I'd prefer to honor "separation of concerns".
So I ask: is there a way to essentially deploy a Java-less WAR on GAE in such a way that it just serves pure HTML/JS/CSS back to any clients that will use it, and to then deploy the server-side in its own WAR, and some how link the two up? Thanks in advance!
The WAR is just for the server side. It includes the client-side classes needed for serializing objects passed between client and server: obviously, both sides need implementations of the same objects in order to handle those objects.
I don't think it will save you any effort or development time to separate the two concerns, but if you really want to, then you can rework your client/server interaction using something other than GWT-RPC. For example, JSON. See https://developers.google.com/web-toolkit/doc/latest/DevGuideServerCommunication#DevGuideHttpRequests for discussion of your options if you want to go down that road.
No, AFAIK, you can not do partial update in GAE, i.e. you can not upload a part of the project to GAE instance and then upload in a separate upload another part (and so separating HTNML/JS/CSS to java classes).
Hopefully this is what you are looking for.
Finally the main stub that you want to deploy might be EAR file which you can mention in main pom.xml
Related
I just need a little hint in what direction my research should go.
Because currently I have a spring standalone jar project (spring-context, spring-data-jpa and hibernate entitymanager. Everything set up without xml files).
Now I want to run this application on two computers inside a network. Both should be able to send objects over the network. But I want to accomplish this without a web server (so no tomcat or glassfish).
Is this even possible? and how is this called?
I have problems finding something close to this plan. Most of the time I find tutorials and threads for sending objects with tomcat. But I more or less only need a open port that listens to incomming objects.
EDIT
Later I also want to put a third player in the communication process: A website. So then two standalone jar programs and one website will pass objects around. That's why I hope spring mvc will work for a stanalone solution as well.
(I know that this question will get tagged down, but it's ok, as long as I get some designations I can use to research better, so thanks ...)
You have many specifications. ProtoBuf seems to be interesting https://github.com/google/protobuf/tree/master/java
Without having server it would be a pain for you as you will have to implement concurrency, security and this kind of stuff.
Does Spring Boot work for you? Server is embeded ;-)
What about use normal java sockets? There is plenty information if you google it. If you need help with this just let me know and I can send you some java application. Just type Java Sockets and lets learn!
Alvaro.
Web services are used to share the services provided by an application, to outside world. This is my basic understanding of web services.
Suppose my application is to expose some specific behaviors and I have written the code for it and exposed the methods. The ones who want to use it can take the link to the wsdl, generate stub and call the methods.
What is the use of doing all this, when I can myself expose the methods, generate a jar and bundle everything in it and share the server address,jar.
How differently is web services important, when compared to a case explained above. Am asking such a general question due to unsuccessful search in many websites.
If you'd generate a client jar, whoever wants to use that would have to deal with Java. If you expose a Web Service instead, the user can use whatever technology he/she wants to use (e.g. Python, Ruby, .net, C, C++ etc. etc.). That would be a huge advantage.
Web service use a series of standards(SOAP, WSDL...) to make different kinds of system work together, certainly you can generate client jar as you like, but that requires your service consumer to learn how to play with it, so it's not a generic solution.
What you are suggesting is quite close to RESTful webservices. Unlike SOAP webservices, RESTful webservices do not require any WSDL files. All that you need to do is to issue a request to a particular URL.
As you explained correctly (in my opinion) SOAP webservices involve some more work which needs to be done, thus making them more complex, if you will, to integrate with other systems. This is not the case with RESTful webservices.
EDIT: You can check out a tutorial here. I have tried it myself a while back and it is enough to get you started.
I'm very new to Google Web Toolkit (GWT) and Google Apps Engine. I want to use Objectify directly in the entry point so that I can utilize GWT in my apps. (I use java)
Is it possible to load Objectify entities directly to the entry points without using any call to server side? I've read several tutorials about this topic but all of them either make a RPC call or use other servlet instead.
OR
Is there anyway to use GWT classes (such as Label, Textbox etc) in a servlet outside the entry point?
I am okay if any of the questions above answered. This is a quite general question, so if you have any reference for them I will appreciate it as well. Let me know if I need to add anything, and thank you!
GWT apps run on the client not the server. Objectify however is server side.
GWT will have to use some way to communicate with the server. Technically it would be possible to write a library like Objectify that does that all automatically for you but that would not be a very good idea as it would require to much communication between the client and the server. The client should send high level commands/queries to the server and let the server do most of the work.
We have multiple web apps on our container (Tomcat) that don't interact with each other but they share the same data model. Some basic data access operations are used in multiple web apps, and of course we don't want the same code duplicated between multiple webapps.
For this case is it better to build a library to provide the common functions or to expose the functions as a web service?
With the library the user would have to provide the data source to access the database while the web service would be self-contained plus have its own logging.
My quesion is similar to this SO question but performance isn't a concern - I think working with a web service on the same container will more than meet our needs. I'm interested to know if there's a standard way to approach this problem and if one way is better than the other - I'm sure I haven't considered all the factors.
Thank you.
I would make them a library. This will reduce any performance hits you would incur from network traffic, and in general would make it easier to reach your applications (because your library can't go 'down' like a webserver). If your applications which use this library otherwise do not require a network connection, then you will be able to totally relieve yourself of network connectivity constraints.
If you think you may want to expose some functionality of this library to your users, you should consider making a webservice around this library.
If it is just a model with some non-persistent operations (non-side effect calculations, etc) I'll use jar library. If it is more like a service (DB/Network/... operations), I'll create a separate webservice. If you have strong performance requirements, local library is the only solution.
Also you can implement it using interfaces and change implementation when it will be clear, what to use.
Webservice will certainly have its own share of overhead, both in terms of cpu and the codebase. If you dont to duplicate the same jar in every project, you can consider moving it to server lib, so that once updated every webapp gets the change. But this approach has a major drawback too, suppose you make some non backward compatible change in the model jar and update one webapp to use the newer model, you will certainly have to update all other webapps to be able to adapt to changes made in the common jar. You cant run multiple version from same server lib. You can package appropriate version of common jar in every webapp, but then for even a minor change in the common (model) jar, you will have to repckage and deploy all the webapps.
I develop Java applications with Eclipse that process data. So far I only developed stand alone applications that take data from file or database, process the data, and output the results to the console/file/database.
I would like put my application online. I never did any web development, but from my understanding, the only difference is that my code needs to be on a web server that can get http requests from users, and return http response based on my application's result.
I would like to get advice on the easiest way I can do this. What technology do I need to learn and what tools I can use for making the transition easier. I would also like to separate my code from the code related to the web stuff.
Thanks a lot!
The simplest approach to developing Java web applications is via the Servlet specification. This lets you load your application into a Servlet container (such as Jetty or Tomcat), which handles the HTTP-side invocation issue. Your servlet is then a front-end for your front end agnostic processing application.
Since all applications require a user interface, take a look at the myraid of possible templating languages available. Velocity is always a safe pick. This will help you seperate the user interface from the adapter code.
While you investigate alternatives, Java Web Start may be the fastest way to get your existing application online. Here's a trivial example.
The easiest is most likely to learn how to write a simple servlet, how the HTML looks that you want to generate and then adapt your existing application to run inside the servlet code, and print html instead of just plain text.
This is described in the Servlet part of the Java EE tutorial (which is not great, but a start)
http://java.sun.com/javaee/5/docs/tutorial/doc/bnafe.html
If you want a more accessible book, I can recommend the Head First series. http://oreilly.com/catalog/9780596005405
For a web container, Apache Tomcat is fine. http://tomcat.apache.org/