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.
Related
As I have understood we use Web services(Rest/Soap) so that a piece of code with some functionality written in one language(say Java) can be used by other programmer no matter the language(say Python) he is developing the application over the internet.
One of the projects I came across uses EWS web services to create,delete appointments on our Outlook 365. The application is developed in Java and a JAVA EWSAPI.jar file is included in the library path(which contains class files like appointment.class,Meeting.class etc) to connect to EWS server and create meetings .
My confusion is suppose we were developing the application in Python, so for that do we have another API (say EWSPython.pythonextension). So then how developing a web service helped us.
I understand API defines the set the methods available and how can they be called with argument.
Please clear my doubts.
I think that you have misunderstood the aim of webservices. We need webservices to make their calls (clients) a platform independent interface which means that once you have created your webservice using any technology (java for your case here) now anyone can call this service by creating a client using any language like python, C#, C++, Ruby, ........... in that case a service which was built by Java will be consumed or called by an application or client created using python and vice versa.
JAVA EWSAPI.jar file is a API Client Library.
What is a client library?
A client library, sometimes called a helper library, is a set of code that application developers can add to their development projects. It provides chunks of code that do the basic things an application needs to do in order to interact with the API. For example, a client library may:
Provide boiler-plate code needed to create an HTTP request and to process the HTTP response from the API.
Include classes that correspond with the elements or data types that the API expects. For example, a Java client library can return native Java objects in the response from the API.
Handle user authentication and authorisation.
How is that useful?
Looking at the developer who’s using the API: With a REST API or any web service API, the developer could be using any of a number of programming languages to make the API calls.
Wouldn’t it be great if we could give them some code in their own language, to help them get started with the API? That’s what a client library does. It helps to reduce the amount of code the application developers have to write, and ensures they’re using the API in the best supported manner.
For more information:
https://ffeathers.wordpress.com/2015/10/25/what-is-an-api-client-library/
I would like to program a WebService embedded on my android device (not the client part).
I've been evaluating Restlet Framework (Restlet) but i don't know if I go on the right way.
What do you think? Is that framework viable for my goal?
Any suggestion is welcome!
Thank you so much!
Regards.
You should check whether Restlet is compliant with android,
not just from server side code, but also from client side code (respectively).
This means for example that every JAR that Restlet framework depends on has to contain code that is compliant with Android.
An alternative approach would be to run a simple HTTP server on your device, for example the following nano http server I read about.
Another interesting project you should check is jetty for android which will hopefully give you support for servlet API as well.
Yes, you will have to spend some time on developing mapping requests and building resource handling logic, but that task is not that difficult:
A. You already have Android code for JSON processing -
For example, look here
B. Using the Java URL object you can analyze the URL of the request and understand which resource you should handle (i.e - add resource to collection, fetch collections, etc).
C. After performing the CRUD operation (i.e - store your resource in some SQLIte table), you can send back a response, and once again, composing JSON if needed is easy.
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.
2 month ago i started to develop an android application which needs to call remote methods and receive complex objects (custom objects with custom feilds in it) from a server.
My friend and I splitted the work so he worked on the android client and i on the server.
Before we started, we built the base interfaces which provide the functions that the client needs from the server, so my friend can program easly the application (by using fake classes as implementation for the interfaces), and after i finish the implemntations of the interfaces in the server-side he will make the connection and call the functions from the server and not from the fake classes.
Now the problem is that we can't find a way to pass those interfaces from the server to the client.
We tried to use java RMI, but we faild because android doesn't support java RMI,
then we tried to use JAX-WS (with tomcat 7) and we also faild because JAXB can't handle intefaces. (-you can see more details here about jaxb issue-)
My friend and I feel really lost.. we don't have any idea how to pass those interfaces between the server and the android client.
Is it possible what we're trying to do? if not,
what other options avaible for us to call remote methods and receive complex objects from the server?
Thanks!
You can expose webservices on the Server, so the client can interact with the server whenever its needed that might be quickest solution.
Or you can write a kind of servlet programming to get the json request from the client, process it and send the json respoonse back to the client. If the application is data intensive, the JSON helps you a lot
Not sure if this is too late now (after 2 months of development), but there are frameworks that should make RPC easier for you (take care of linking both ends). Two I know of are Apache Thrift (definitely usable with Android - there are apps that use it) or Apache Etch (possibly).
Apache Thrift:
http://thrift.apache.org/
Apache Etch:
http://incubator.apache.org/etch/
Blog about Evernote choice of Thrift:
http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/
If your application is limited to communication between Java on the server and Android (no other clients e.g. IOS) then an easier RPC path compared with IDL based solutions is to use jsonrpc. This solution provides both server and Android client components. It is extremely easy to implement on both client and server. One limitation is that byte arrays have to be encoded because the JSON transport does not support binary.
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.