I have a diagram editor application (client), which is written in javascript. I need to take the model of the diagrams (can be transformed to text), and synchronise it with my GAE Java application which will be my backend. The application will then store this model on cloud, or send it to other clients. (as a result many people work on same diagrams)
This is a totally new field to me, and even though I completed some of the tutorials google provides, and gone through documentation, I am not sure how the connection will be done (tutorials used JSP).
What is the most straight- forward approach into connecting a Java
application (GAE) with a JS client ?
p.s: I have read about ajax, but I dont know if its the right solution for this, or if there is a better one.
What is the most straight- forward approach into connecting a Java
application (GAE) with a JS client ?
Through an API built on HTTP. Your JAVA web app can expose certain endpoints. You can then use Javascript to make http requests, (through AJAX) to your java web api). This is currently the defacto way of communicating from front end with javascript to any backend service.
There will be some trickiness to supporting real time collaboration between clients.
Additionally, there has been increasing support for websockets, which allows you to open a persistant connection between your client and your server, i don't know if java on GAE supports it though...
Related
In my project need to create the following architecture:
Front-End application is a web site resource that will combine HTML+React technologies.
Back-End is a java application that will be connected to Mongo DB to operate with data.
Now, in the middleware should be placed Node.js. And after reading a lot of info on the internet, I have now some confusions regarding this.
As I understand Frond-End will be routed to node.js (and now the question is it Express.js-- the same thing or it's different) which is also connected to Mongo Db and Java application(this is doing all logic).
Can someone explain me should use express.js with the integration of node.js in order to route to java server application?
If you want to use a middleware. Nodejs can help you do that in a lot of ways, you can use express.js so that you won't have to do more request/response parsing work. And when you want to connect to your java server using nodejs, you can also integrate that by calling the java server API endpoint by using some http library like axios then you can directly communicate to java server app to directly communicate to the backend mongodb.
But your Front-End application can also directly communicate through your backend java by creating a REST API. And store all your business logic in the java REST API.
I am developing a chat website that makes use of the Openfire XMPP server, with the client side using Smack API. The web project that makes use of the Smack API is implemented using the Play! framework making it RESTful. I chose Play! because of its Asynchronous Programming offerings (Comet Sockets/WebSockets).
Basically, my architecture, so far, is like below:
Openfire <-> Webserver <-> User/Browser.
In order to support Android devices too, and to maximize code-reuse, should I implement the XMPP client side code as a RESTful webservice that is common for both the web site and the Android clients?
Openfire <-> Webservice <-> Website <-> Browser/User.
Openfire <-> Webservice <-> Android App.
I'm afraid of scalability issues, because of the introduction of an intermediate web service? Would I be introducing latency in the communication as a result of having to go through multiple components?
Any advice on the above would be helpful. Thanks.
The key to scalability is decoupling. So in an essence you can think of the problem in terms of "If one of the components fail, will the other components continue to work normally?". In addition to avoiding end of the world scenarios you can also independently scale horizontally each component.
With that in mind lets now move on to your specific use case. Layers for the sake of layers are what still make me see nightmares about some Java EE architectures around. Not only does it introduce unnecessary latency, it also makes it harder to pinpoint a problem. If your service fails, was the failure caused by the web server, android application or the web service?
If you want code reuse, reuse code instead of duplicating components. That`s what libraries are for. Take your common code and extract as a library and use it in both the web server and Android application.
I think that the best it to make a light webpage that consumes directly the webservice (like any App) from the browser once it's loaded.
So the only difference between the App and the Webpage is that the webpage will be loaded by the browser each time the user access to it.
I am developing a mobile application for Android. The application will act as a front-end for another GWT-application I have running on appspot.com. To communicate between the two, I need to send data from the client (Android Applcation) to the server (GWT-application), which must then be processed and data sent back to the client. What would be the best way to accomplish this? By "best" I mean simple enough for me to understand and implement, but also in line with good practice.
Any advice is greatly appreciated, as I am very new to GWT and can not find a lot of support on the internet.
Thanks!
I don't have much experience with Android application development but I guess with "sending data to the GWT application" you mean sending data to your App Engine backend/server.
In the end GWT is just compiled to plain Javascript and runs in the browser. So I don't see how you want to communicate with the GWT part of your app.
However you can send data from your Android app with the backend running on App Engine and eventually the data can be displayed in your GWT application accessed by any browser (mobile, desktop, etc).
For that I think you can either go one of two routes:
Create an HTTPRequest from your Android app to the backend using JSON or XML as a data protocol
Use RequestFactory (internally uses JSON) in your Android app (There is a special Requestfactory_client.jar package for that. See here for more details).
We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez
It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.
I am new to appengine. I will write application which consist of two parts.
1) Core written in app engine with REST interface for clients.
2) Client application written in J2EE on my other (not appengine) server. But here, client may use any other technology (android, swing etc.)
I dont know, how to handle authentication of users in this schema. I think that I am in the middle between standard login and installed applications.
The simplest solution that occured to me, that the client will request username+password, pass it to appengine application via https and it will authenticate.
But dont know how to synchronized the login with client app, because it will need also data from google applications...
Is there any solution or pre-prepared facility in Java how to handle this?
Thanks
You probably want to use OAuth for this; client login or using username+password is not a good way to do this, and informed users will be -- or SHOULD be -- hesitant to give away their passwords. There is a page for using OAuth within AppEngine applications written in Java which may be of use. There is also some support for Oauth in the GData client library for Java. The OAuth in the Google Data Protocol Client Libraries document may help you to understand how to use those features.