We are about to create a mobile version of our web page. In that page we have used RPC services in a service way, not totally entity oriented. So we are going to have two clients (web and mobile) calling one server.
Now we want to reuse all that server code supporting several client versions and avoiding all the "dto version hell" that the RPC calls have.
I have seen that we need to create a wrapper, another layer in the server, for exposing methods to the mobile versions (GWT+phonegap and in the future: IOS, Android...). Later this layer would reuse all the server code (model, repositories... etc), in the server the access to BigTable is done through Objectify.
Which technology would you use for this new layer?
For mobile apps I like to use AutoBeans + RequestBuilder on the Client and AutoBeans and Restful API which (also) produces JSON on the server side.
With AutoBeans you define the structure of your data with Java interfaces. (Which gives you something to program against) and AutoBeans handles the conversion from Object to JSON and from JSON to Object for you on the server and on the client as well.
In combination you can build a very fast and good architectured RPC. AutoBeans is used by RequestFactory as a default mechanism for serialization.
If you ever decide to support other platforms you can still use the JSON and parse it there. If you decide to support a native android application the AutoBean mechanism should just run fine on the android vm.
A good example for AutoBeans can be found here: http://code.google.com/p/google-web-toolkit/wiki/AutoBean
Related
If not is there a way to build it on both devices, independent of the application, and then have it be accessible from inside the app?
The possible approach I see here is having the 2-part infrastructure based on API. For this purpose you need to be really eager to learn networking at least a bit, however it has many benefits for the future.
Unity app as a networking client sending API calls to your back-end server (currently Unity supports WebGL and UDP low level transport API https://docs.unity3d.com/Manual/UNetUsingTransport.html). These API calls can be in the form of data-interchange format like JSON or XML. JSON example: ["signup", {"name": "SomeUser", "pass": "SomePass123"}]
Back-end network server client, which receives the calls. Logic for writing to and reading from the database is purely in this back-end. It sends the result back to the client again in the form of some data-interchange format. JSON example: ["success"]
This way your Unity app will be absolutely independent from any kind of database. If you will want to change the database in the future, you just rework your database handling on the back-end while reusing same API calls! Or you can have multiple front-end client apps based on different technologies accessing the same API.
Now the approaches to Unity and networking for your custom back-end:
High level approach
For pure Unity-based networking you can use Photon
(https://www.photonengine.com/en/PUN) or Unity High Level networking
API (https://docs.unity3d.com/Manual/UNetUsingHLAPI.html).
Lower level approach
You can have your back-end based on entirely different technology
too! In that case for Unity client app use Unity's low level
networking Transport Layer
(https://docs.unity3d.com/Manual/UNetUsingTransport.html) and your
back-end's networking layer can be based e.g. on Python (e.g.
Twisted), JavaScript (e.g. NodeJS) or any other.
Even Lower Level approach
You can go even deeper and use .NET Sockets for Unity client (but
you need to have Unity Pro subscription, otherwise they don't let
you build your app) and any low level socketing libraries for
back-end, e.g. C# .NET Socket again, Python socket or, bit
higher level, socketserver.
WARNING!
Note that if you want to port your app for browser, you must use websocket, not TCP/UDP.
Neo4j on different back-ends:
C# (.NET) - https://neo4j.com/developer/dotnet/
JAVA - https://neo4j.com/developer/java/
JavaScript - https://neo4j.com/developer/javascript/
Python - https://neo4j.com/developer/python/
Not really, there is an older version of Neo4j ported to Android (Neo4j 1.5).
Otherwise there is a Swift/iOS driver (and of course java drivers) for Neo4j.
I have a Dart project want to reuse the existing GWT service (RemoteServiceServlet), any way can do this?
There is no special support for GWT-RPC included in Dart and there seem to be no 3rd-Party apps available that provide this functionality.
This question is similar (but not Dart)
GWT Data Serialization
If you're feeling ambitious, you can write a Dart client that understand the GWT-RPC wire-protocol and use that to communicate. This is likely to be a great deal of work however.
I had a similar situation where I needed to access GWT-RPC Services from a non-GWT client (it was JavaScript, not Dart, but the same concept applies). Instead of accessing the GWT-RPC service directly, I ended up using jsonrpc4j to setup a JSON-RPC service alongside GWT-RPC. I was able to point jsonrpc4j at the GWT services to use, so there was no code duplication, just the extra code needed to wire up the JSON-RPC.
Then you will need a Dart JSON-RPC client, of which there are a few available: jsonrpc, jsonrpc2.
This all assumes that you have access to the GWT server and can setup the JSON-RPC service.
I want to implement REST service in gwt .But I don't know how to go about it. I read some documents where they have implemented it using RestyGwt and jercy. But I have one app which is deployed on tomcat. Then situation is that my client side app is calling the methods on the application present on tomcat.
I have to implement it using REST so that my client side call will first go to Proxy service on client then it make REST call to the application on tomcat and fetch result and return. How can I do this in gwt. ?
As mentioned, you can only communicate with REST service.
Anyway, maybe take a look on dispatch concept in GWTPlatform and their way of implementing it. (https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch).
Idea is easy, you have an action on client side which is registered to deal with rest url. You can define action interface with some additional annotations to tell what is excepected to be send and received. They are using piriti library for json serialization.
It is up to you if you need only client side implementation or you would like to use server side service creation too.
You can NOT implement a REST service in gwt, since gwt is thought as a client-side solution.
What the GWT kit provides for server side are a few utilities to facilitate the comunication between client-side and server-side when both are written in java (RPC, RF).
So you can consume a REST service from gwt (RequestBuilder, gwtquery-ajax, etc), but if you want to provide REST services you need a 3party solution for your server side like Jersey, CXF, etc.
There are, though, 3party solutions which provides the server side and client simultaneously like restygwt, errai-jax, etc.
If you are looking for a simple and reliable solution to query rest services from the client, in this question you have a client implementation done with gwtquery (ajax, databinding, promises)
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 want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>