Can I use both in the same project? Or do they cause "network interference" with one another?
You can use simultaneously any Ajax mechanism in GWT, they are not exclusive, so you can select the most suitable one for each necessity in your product.
For instance, I have an application which uses RF for entities and business requests, gwt-atmosphere (which uses RPC) for comet comunications, and gwtquery-Ajax (which uses RequestBuilder) for consuming 3party json services.
It does not cause any kind of interference. In the end you are just sending HTTP request to a servlet. You client can handle (pseudo) simultaneous queries as your server.
So you can use different method to query your server. The point is more about maintenance/re-usability/readability of your code.
I would advise you to use only one way for querying your server.
IMO you should avoid using RPC as much as you can and look into more standard way of communicating with your server (RequestFactory or simply requestBuilder or even REST libraries like restyGWT) so that your server is not linked to your GWT client.
Related
I want to store raw request and responses (XMLs or JSON) in database for Wbservices and HTTP calls in a Java Web application. How do I achieve this without degrading performance of the services.
I have seen few implementations like -
Asynchronously using IBM Workmanager
(com.ibm.websphere.asynchbeans.WorkManager). This will do the job in a separate thread - I can't use this
as this is more specific to IBM Websphere application server
Using Spring AOP - Apparently its more complex and as per my understanding Spring will not create a separate thread and may degrade performance.
Is there any other way (better way) of implementing this? Any other third party library which does the same work as above mentioned IBM Workmanager? Any suggestion is most appreciated.
You can pass your request and response to a method annotated with Spring's #Async:
Creating Asynchronous Methods
I have a JRuby/Rails app that needs to get data from a system written in Java. I have already worked out how to call Java code from Ruby.
However, lets say that the Client object I need to create, starts threads, communicates with the internal system etc, and that the data is delivered asynchronously in callbacks.
Do I have to write a separate web service (that creates this Client) with a permanent connection to the Java system? In such a way that my Ruby/Rails code can call it synchronously. Or is it possible to write this asynch handler directly in Rails?
When multiple HTTP clients issue their GET's, I would of course have to connect to the Java system when the first client arrives. For the following clients, the data would already be there.
I realize what the proper solution would be, but I'm curious whether I can do it all in Rails.
I can (for now) live without the realtime updating of the webpage, as long as the data in the Java callbacks are stored "somewhere" so that the next HTTP refresh/GET can return it. Nest step would be SSE, Javascript etc.
I think I know how to create the Java web service, however I would rather keep the solution a bit simpler with fewer services.
Thanks
Since you also have access to the java code, I have two approaches to extend the java backend, in order to provide the data you want to use in your ruby frontend application.
Use REST or a HTTP Service
Your ruby webservice could interact with the backend utilizing REST (or any other HTTP approach). This would result in cleaner and more reusable code. Since you're able to access the backend data with any client that is capable of HTML.
Use TCP together with a little protocol
In this approach the clients have to connect to a TCP socket on the backend to send data back and forth. You have to write a little byte or string based protocol which you also have to parse. It's more complex than the first approach, but also more performat and you don't have to rely on external libraries (e.g. jersey, for REST). It also has all the advantages of the former approach, you can serve any client capable of network communication and socket handling.
I have a Spring-MVC webapp (3.0.5-RELEASE) which needs to access JSON webservices from another webapp on a different sub-domain (from the client/browser via AJAX).
I've solved this in the past by either:
writing a simple controller that proxies the requests, using Apache Commons HttpClient to handle the requests. Thus overcoming the cross-site/cross-origin request security limitations of most browsers
implementing a JSONP service on the server side (when calling our own JSON services) - not always possible
In the case where JSONP is not possible, is there a better way of doing (1.)?
and/or
Is there a library that will handle this for me? So I don't have to write all the HttpClient code myself - its not a lot of code, but I wonder if I'm (badly) re-inventing the wheel.
I have often had to consume third party web services (API), and as you mentioned, JSONP is not always an option. This is how I go about designing:
If the API is user centric, it has to provide a jsonp interface and that's what I will use. User centric means that you cannot perceive any reason to call the API, do some computations with the response, may be call one of your ajax services and then combine the response and show the user.
If my use case includes calling the API, and then acting on the response, like calling additional services from my application, combining the data and then showing it to the user, I would prefer not doing this in the browser. I would instead use RestTemplate and make backend api calls to the service. In which case there are no cross domain restrictions.
The only case where using a Server Proxy to bypass jsonp is when you are creating a Product that allows people to build custom plugins, plugins which are hosted on your page, but need to make Ajax calls to the app developers servers. This is a very involved case! (As as example look at how Apigee creates Public Facing REST API around your existing urls, or how Zendesk allows you to develop apps)
Hope this helps.
I'm writing a web application with GWT and I've to call google calendar's API to retrieve some information. I now have this dilemma: Is it better to use a client side invocation (using javascript or gwt-gdata library) or using the standard google library for java to call the service at server side and then passing all the data to the client via an async call?? I'm not able to understand pros and cons of the two approaches... In particular, I need to call several time the calendar API to retrieve events and let users add new ones, etc.
Can you help me?
I would call it from the server-side. Why ?
it means your client-side view code is dedicated to providing a view only. You're not confusing matters by calling multiple services, and you're enforcing separation of concerns.
you can make use of strategies such as caching on the server side.
Check the performance of using the server-side library. I found with the search library, that the round-trip time from client to server and back to the client was too slow.
GWT RPC is proprietary but looks solid, supported with patterns by Google, and is mentioned by every book and tutorial I've seen. Is it really the choice for GWT client/server communcation? Do you use it and if not why and what you chose? I assume that I have generic server application code that can accommodate for RPC, EJBs, web services/SOAP, REST, etc.
Bonus question: any security issues with GWT RPC I need to be aware of?
We primarily use three methods of communications:
GWT-RPC - This is our primary and prefered mechanism, and what we use whenever possible. It is the "GWT way" of doing things, and works very well.
XMLHttpRequest using RequestBuilder - This is typically for interaction with non-GWT back ends, and we use this mainly to pull in static web content that we need during runtime (something like server side includes). It is useful especially when we need to integrate with a CMS. We wrap our RequestBuilder code in a custom "Panel" (that takes a content URI as its constructor parameter, and populates itself with the contents of the URI).
Form submission using FormPanel - This also requires interaction with a non-GWT back end (custom servlet), and is what we currently use to do cross site communications. We don't really communicate "cross site" per se, but we do sometimes need to send data over SSL on a non-SSL page, and this is the only way we've been able to do it so far (with some hacks).
The problem is that you are on a web browser so any non-http protocol is pretty much not guaranteed to work (might not get through a proxy).
What you can do is isolate the GWT-RPC stuff in a single replaceable class and strip it off as soon as possible.
Personally I'd just rely on transferring a collection of objects with the information I needed encoded inside the collection--that way there is very little RPC code because all your RPC code ever does is "Collection commands=getCollection()", but there would be a million other possibilities.
Or just use GWT-RPC as it was intended, I don't think it's going anywhere.