I developed a web application (works properly) which registers a user to the system and allows user to upload a file to system via https. The client side code is totally developed by using GWT 2.4 and the back end is several servlets. Except the upload code, all the client-server communications are done via using ServiceAsync interface as it is the common practice in GWT. The upload code is based on a form which is communicating with the upload servlet directly.
This project is developed as a course work and my Professor is keen on knowing the underlying architecture of google web toolkit specificly focused on the client-server communication. His question was,
"How the client code knows the server's url so that all the communication is done?"
His question is legitimate for the ServiceAsync interface. I am calling a function on the server side which seems interesting to him and he wants to know the underlying process behind it.
For uploading, I just defined uploadForm.setAction(GWT.getModuleBaseURL()+"upload"); where upload is the name of the upload servlet in web.xml.
I told him that the compiler generates Javascript code which contains all the web application code (whole system developed dynamically) and the url to the servlet is placed in that script file however the answer did not satisfy him. Please let me know the inner facts of the client-server communication with GWT.
Please give me some answers that can help my Professor to understand GWT's asynchronous client-to-server RPC communication.
The underlying technology is shown here as a diagram. Google says "GWT provides an RPC mechanism based on Java Servlets to provide access to server side resources. This mechanism includes generation of efficient client and server side code to serialize objects across the network using deferred binding."
The client knows the URL to query because you would have annotated your service interface with a #RemoteServiceRelativePath tag. This associates the service with a default path relative to the module base URL. That URL is where Javascript sends your request.
There's a lot more to learn about GWT's RPC if you care to, and you can start picking it apart here and here.
There are multiple ways in GWt how to bind RPC service to the specific url.
First is an annotation #RemoteServiceRelativePath which is placed on synchronous interface. Using deferred binding rule GWT will discover this URL and will set it to the service instance automatically.
Second is casting instance of GWT-RPC async service to the ServiceDefTarget and setting an url manually.
But this answer alone will not satisfy your professor, because most likely he will want to know some other details, so I recommend you to learn how exactly GWT-RPC works.
Regarding the basic question of how the client knows the url of the server, it sounds as though the professor may be asking about the full url of the site (the domain name), and not just the sub-directories for the services as they are defined in #RemoteServiceRelativePath and the web.xml.
For this more fundamental aspect of the question, I think the "Same Origin Policy" (SOP) that browsers have for javascript security could be an important part of the answer. This is explained in one of the GWT FAQs. The first thing that the browser is doing on the client side (after the HTTPS connection is established, which I think could be another important part of the answer) is reading the host html file, where the bootstrap nocache.js file is referenced. Once this file is loaded, the SOP is going to guarantee that all of the subsequent JS application files are coming from the same server as the bootstrap and the host html files. Once the application files are loaded, then everything is happening within that context, with specific internal url paths being defined for RPCs as already mentioned.
Related
I have experience with other enterprise CMS's like Teamsite & Tridion, but no hands on experience with CQ5. I'm wondering, how is CQ5 usually integrated with a large site that has content & functionality? Functionality defined as pages are generated with data from a non-CMS repository or webservice.
My question is, is CQ5 content read in as a back-end service? I know the API is http based. But is that API typically called from server or client? For my example, lets say I have a page that is from mostly driven from a web service that is linked to some non-CMS enterprise system, but I want the footer & right rail to be "content" so that the users can change it easily. At what point would the the different page sources typically be combined?
I'm wondering because I work with asp.net. I know the CQ5 is Java, so I would expect that most cusomters are java shops, but I would think that the HTTP would be easy to consume for an ASP.net site, if it is really just another backend webservice.
Your question is really not all that clear to me to be honest. So I'm going to answer this rather broad.
To answer your question about the different page sources:
The client usually initiates a http or json request to the server (although server to server calls are not uncommon in case of extended infrastructure) and the server simply executes the necessary calls (using the apis) and delivers the answer to the request. But at the point of request return, all calls to the api have been made by the server, and the server is just returning rendered html or json, or whatever structured form you want to have your data and/or content in.
A page consists of various components. Some components are fairly static. Others are very dynamic and pull their data for example from a webservice, or external database or even another cms. The combining of these resources happens upon the rendering of the page which in its turn was triggered by a request for that page. The obvious exception is ofcourse the dispatcher caching system which will return a cached version of the page if possible. But in short, all the rendering and api calls are made server side.
CQ5 is fairly flexible since it's split up into 2 instances. The backend (author) which is where the actual authoring of pages happens. And the frontend (publish) which is basically the frontend, and does the actual rendering for a client (usually).
Wether you choose to use the publish instance a backend service is just up to you to be honest. I've seen cq5 used as what it was ment for (cq5 being the frontend), and I've seen cq5 used as a backend service (for example: as a backend service provider for hybris). And I've seen the combination, where one part was used as backend service for another system, and the other part was used for a public website frontend.
CQ's rich HTTP API (based on Apache Sling) gives full access to the CQ content in various formats including JSON and XML, so integrating CQ content in other systems is easy.
In the other direction, you can use Sling's ResourceProvider mechanism to access external content and make it part of the CQ content tree. See "custom resource providers" in the Sling Resources docs at http://sling.apache.org/documentation/the-sling-engine/resources.html .
I am new to the Play! web framework, and in order to understand how it works, as well as how it compares with other web frameworks, I would like to be able to trace, in the Play! source code, the request lifecycle from start to finish. I will be using the Scala implementation of Play!.
Because most of my experience has been with PHP frameworks, I am used to starting with an index.php file in a web root directory and reading down through any included config/bootstrapping scripts, dependency injection handling, request routing, action dispatching, and finally view/response rendering.
I have not been able to identify a similar point of entry for a Scala/Play! application, and I would very much appreciate a push in the right direction. A walkthrough of the request lifecycle would of course be very generous, but all I really need is to be shown the entry point.
By default Play framework uses built-in HTTP server (based on Netty). So closest analogy with PHP will be that Play is both Apache and PHP.
PHP uses legacy 'CGI-like' paradigm: to serve single HTTP request, your program is started and after finishing serving request it is terminated. In CGI to serve an HTTP request webserver starts external program -- your script -- and returns its output. Older versions of PHP was designed only for CGI, in later versions other ways to interact with server, because CGI is very slow, but core principle remained the same.
Most of web application technologies use another approach: your web application is started one time then stays running, so one running instance of web application continues to serve requests (and can serve multiple requests in parallel). It does not die after serving a single request, as in PHP. This allows to consume much less resources required for starting application each time, and only just slightly harder to work with, because most of request processing in hidden inside framework, and your app only needs to expose controller methods that are called when request arrive and return response.
It also allows for more flexibility, for example background processing can be started right inside web app, no need for external server processes. Play has Akka library that is very convenient for this.
As more and more web applications use Ajax and REST approach, instead of serving heavyweight webpages each time, it becomes more important. And it is almost impossible to create realtime messaging backend with PHP that will have good performance, regardless of requesting technology (polling, long polling, iframe with multipart).
But if compared to PHP MVC frameworks, from point of view of developer that creates views, models and controllers, Play is very similar. Both in PHP MVC frameworks and Play framework calls controller method or function and this method should return response, views are usually templates and models are usually ORM bindings to relational database.
I think this is the file you mean:
https://github.com/playframework/playframework/blob/master/framework/src/play-netty-server/src/main/scala/play/core/server/NettyServer.scala
Play is a Java application that starts listening at a given port. Listening is done using Netty library which understands different types of network protocols (most importantly HTTP). Once Netty knows whats happening it will give control to the Play framework.
The Play Framework will then use the Global file in combination with the Routes to determine what Action to invoke.
Play is more of a restful framework ( read http://en.wikipedia.org/wiki/Representational_state_transfer) rather than a typical template based frameworks like jsp jsf etc with a request lifecycle concept, although it does have templating support too. The basic idea is too have the interaction with server based on pure data like json and most of the code for update of dom structure is written in javascript and is done on client only which is actually more flexible and a lot simpler and efficent.
In play you just plainly create your methods for sending data to browser by defining a method in your scala class and mapping it in a routes file. Also like in a typical web development process you also place you html files in a public resource folder ( or create a template ) which will typically do a ajax call to that method when executed in browser.
I have read through the chromiumembedded usage and looked at the cefclient application. Now i would like to provide my gwt application as an standalone application to my customers. Is it possible to package the gwt client code using chromiummebedded.
I am not sure how to make the RPC/RC calls to the server if its packaged in CEF.
I think you need to include an embedded webserver in your application, and serve the generated GWT application files from this.
Since the url for your server will be different, you could disable the same origin policy in ChromiumEmbedded to use normal RPC calls, but it might be better to use cross domain calls as describe in Googles tutorial
Is it possible to write a server side of GWT application in other languages then Java if yes how to use GWT-RPC mechanism, an sample code please
Thanks
Please read the GWT documentation Communication with the Server:
If you can run Java on the backend and are creating an interface for your application's server-side business logic, GWT RPC is probably your best choice. [...]
If your application talks to a server that cannot host Java servlets, or one that already uses another data format like JSON or XML, you can make HTTP requests to retrieve the data.
You can write your server in any language you choose, GWT is just JavaScript to be run in your users' browsers.
If you decide to go that route, you should look into using RequestFactory to communicate with your server instead of GWT-RPC, which is Java-specific. RequestFactory uses standard JSON, which any language can read/write.
Dont waist your time with GWT-RPC. It's bad. Use RequestFactory. I am surprised people are promoting GWT-RPC. It's a broken toy.
I am trying to do some cross-site in GWT.
According to GWT:Same Origin Policy I've added to the module xml file.
It is working okey as long as I am not calling any GWT remote service (using GWT-RPC), but when I try to call any remote service, I got no response!
Any one know how to fix cross-site issue in GWT with GWT remote services?
Thanks in advance!
Steve's answer is correct, however there is one other option you can consider which is the best approach if you want to require authentication for server interaction without using OAUTH. The main point is that the cross-site linker doesn't bypass the SOP, but allows you to host the index.html on a different site than the JS code so that you can have the JS code and servlets on one server and load them from another. To get around the SOP you can use a method called JSON with padding or JSONP. Essentially what it does is use a script tag to inject a foreign request into the environment by wrapping the requested data in a callback. To do this you can use one of many server-side implementations such as Jersey. GWT 2 includes a JsonpRequestBuilder object which does all the client-side work for you and can be used in the same way as RequestBuilder. See this article for a tutorial.
If you want to access some other server (example.com) from your GWT app, then you'll have to do an RPC to your server, and in your server-side code, you'll have to make another HTTP call to the example.com page you're looking for.
The page you linked to regarding cross-site linking outlines that adding <add-linker name="xs"/> to the module file allows you to split your hosting between 2 servers:
One server for static files (all GWT produced html and js files, and all images)
One server for dynamic calls (all your RPCs go here, and your index.html home page must be here)