I am building an application with java enterprise and glassfish. The information between client and server will usually be small amounts of data, but from time to time the client will need to get a larger resource (1-20 MB would be typical). I am still planning the architecture of the system, and I need some advice about how to expose resources on the server to multiple clients.
Originally I was only going to have a desktop client app running in the ACC provided by javaws and glassfish. I put the remote interfaces in a separate jar, and planned to do all client server interfacing by calling EJB methods exposed through those interfaces. This is all fine and well for a java desktop client. It should even be pretty easy for an android client. But I don't think its going to be as easy for ios.
Is there any way I can call my EJBs from the objective-c running in an iphone or ipad? I surely hope so.
Im anticipating that the solution is a RESTful web service. From what I understand this is a way to loosely couple client and server applications by passing the data in a generic XML or JSON form.
Sorry if I am missing something very obvious, but it seems like there are two routes from here:
keep my EJB business interface and implement a duplicate restful interface for generic clients (iOS and whatever else might come up later).
create one restful interface for all clients.
number 2 seems like a much cleaner design, but it means I have to scrap work ive already done and learn about rest. Can someone with more experience offer some suggestions? I would appreciate it so much.
In EJB 3.1 you can expose you business logic as a RESTful service in a very simple way, e.g.:
#Path("name")
#Stateless
public class NameService {
#EJB
private NameBean nameBean;
#GET
#Produces("text/html")
public String getHtml() {
return "<h2>Hello "+nameBean.getName()+"</h2>";
}
#PUT
#Consumes("text/plain")
public void put(String content) {
nameBean.setName(content);
}
}
No need for servlets or any other delegate. It's absolutely fine to have various access methods for one logic so that some java clients use EJB (RMI) and others use REST. In the future you may even add some new ones if needed, e.g. XML web service, through asynchronous messaging and so on.
I would suggest Option 2 with one modification, dont even bother to create a web service.
Use a plain servlet which returns JSON to be consumed by Android and iOS
Related
May be my question is a bit ambiguous so I'll try to explain it clearly:
Normally I work with ASP.NET MVC and write back-end for the websites. So 99% of data comes from the user's input to forms and sent to views.
Now I would like to implement web-service based on ASP.NET : here what I want to do:
My mates write the same application on Android and iOS. I write web-site with the same functionality. The applications collect some data (inputs, Geo-locations, etc.) and should send it to the common DB (SQL Server).
Respectively, web-service should send back some data.
I have no experience of writing service that get and post data to different platforms but have some idea how to do it: JSON or XML supported by all devices, so before post-get process I should convert data (no matter CLR, JVM, iOS) to JSON/XML and get\post (send, recieve) it.
I want to do it with hosting the server on Azure.
Could you prove that I am thinking on the right way or show what mistakes did I do? Is there any topics I need to learn?
More clearly, here are the questions:
What should I learn in order to implement it?
Is it good idea to use Azure\SQLServer with Android\IOS?
Will I need to write my own API or there are ready solutions for cross platform communication (data-exchange)?
You should learn ASP.NET Web API and not use a ASP.NET WCF web service. WCF is not cross platform compatible. Web API is because it is compatible with the REST (representational state transfer) architecture and all the platforms you mentioned can use REST for their calls to your RESTful API.
I don't see any reason why you shouldn't use Azure if that's what you're comfortable with. The Android\IOS applications will be talking to your RESTful API so the backend you use is not relevant to the consumer of you API.
I want to make an app on Android using MySQL.
I'm new here, so I first see many other's app design. I find one thing is that if they have to use database, they often use RESTful design, defining some API for HTTP protocol for client/server side communication. And then, there're lots of things to do, like: mapping resources into url, sending/recieving doGet, doPost,.. requests.
But I don't understand. This is an app develop, not a web develop. Why do they have to make an app so much like a web? If I don't want to use phoneGap, HTML5, .. that kind of HTML-based develop, I want to write a native app. And I still want to seperate client and server end in my code, my server side could communicate with MySQL, and my client side display it to user, and they're all written in java. Since they're all java, so I got a native idea:
"why don't I call my server side code directly from my client end?"
Since it's all run on an app, there's no necessarity to map it into a url for user to access. But as I observed, most of people don't do this. So I want to know why they donnot make their app the way I think? Is it for security concerning? Or to reduce debug difficulty? Or for later expansion to other platform like iOS?
I want to know why they choose HTTP based client/server communication.
It's not just about security, because in either way you'd be setting an external Socket to the destination, but also because there's no native way to communicate between you app and MySQL. The most common approach in this way is using a web-service, where you'd implement a HTTP server with some code in your favourite language (PHP, Python...) that would process your requests made by your clients and process them accordingly. This third-party script would communicate with the database.
If you finally choose this approach and you're concerned about security, I'd choose some asymmetric encryption algorithm as TLS, where you could encrypt your messages with the public key and decrypt them in the server side with the private key.
You can share the public key with no concerns, you can simply embed in your code, but you could also put it in your web-server and make your clients download it each time they connect. This way, if some day you change it (because of a Heartbleed situation, for instance), they'll always have the current public key; otherwise, you'd need to update your app if you hardcode the public key in your code.
Some useful links:
Android Encryption with the Android Cryptography API
Create SSL-Socket over SSL-Socket with Client Authentication
How dangerous might be publishing a public key?
I have read countless posts regarding the use of JDBC with Android. Everybody suggests to take the path of using PHP scripts and using HTTP clients within the Android code.
It would be great to just get a clear indication as to why the JDBC is not advised.
JDBC access directly from a web client, be it browser or web phone, implies that the database port is exposed on the public internet. That's not a safe place for any data to be.
I think a better approach is to put one or more servlets between clients and the database. Let the servlet(s) handle security, validation, binding, deciding which services to invoke to fulfill the use case, marshaling the response, and routing to the next page depending on the outcome.
This design lets you put the intermediate layer on the internet and keep your data safe behind a firewall.
It's called Model-2 MVC. It's been the standard idiom for Java web development for more than ten years.
You'll get a lot more use out of your code if you have a clean separation of the presentation of data from how it's produced. UIs come and go, but services and data linger. Think in terms of services first and you'll do better.
The current solution that I have to adopt uses JDBC and stores the user/password of the database inside the android app. That's as far as I'm concerned not a good solution. I would like to implement a mapping layer on the webserver in the middle.
Is there any best practice or recommended strategy for this? Should I use SOAP or JSON or something completely different (because they're well implemented and/or easy to use in Java)?
Are there any mapping tools for postgresql <-> SOAP/JSON/whatever in PHP or will I need to write these scripts by myself?
Any pointers will be greatly appreciated.
Quick version:
Use a web service midlayer running on a public host you control (possibly but not necessarily the database host). Expose public web service methods to do the limited work you want to permit and nothing else.
Related questions:
Driver JDBC PostgreSQL with Android
How to connect to a PostgreSQL server via JDBC in Android?
Implementation options
Personally I'd use a Java application server like Apache Tomcat or JBoss AS 7 and I'd write my web service methods using JAX-RS to produce a nice REST-style API for my app to use. That's what I'm familiar with and it works well, but you have lots of options including implementations of:
REST-like APIs (Java's JAX-RS impls Jersey and RESTEasy, various other langs tools) that use HTTP requests and produce JSON or XML replies.
SOAP with WSDL, the classic "web service" layer. In Java done with JAX-WS among other options. Most languages have tools for SOAP+WSDL but it's kind of crappy to work with especially on intermittently connected devices like mobiles.
XML-RPC if you like pain
There are some JAX-RS quickstarts on the JBoss AS 7 quickstarts list; just search for "JAX-RS". The "kitchen sink" quickstart is useful, though perhaps not ideal if you're not familiar with the basics of JBoss AS 7 and Jave EE 6. Fort the JAX-RS specifics you're better off with a Jersey or RESTEasy tutorial like this or this.
Important considerations
Use HTTPs if possible, and if access isn't to be public use a suitable HTTP authentication scheme like HTTP Basic auth over HTTPs. Any decent web services implementation will offer authentication options or support those of the platform on which it runs. Avoid the temptation to implement your own authentication and user management at the web services layer, you will screw it up; use the auth at the HTTP layer that's already written and tested. This may require the use of something like Apache's mod_auth_pgsql, JBoss AS 7's JDBC security realms, etc. The only case I'd consider not doing proper per-user HTTP auth is where I don't need to separate my users for security reasons, I only care that it's my app accessing the server, ie if my security requirements are quite weak. In this case I'd use a fixed username/password for the whole app and possibly an X.509 client certificate if Android supports them.
Remember that no matter how you secure things, all credentials are either known to the user or can be extracted trivially from a .apk so you still have to assume anybody could access your web service methods, not just your app. Write them accordingly.
Do not just send SQL from your app over a web service call to the server and return the results as JSON. This is horrifyingly insecure, as well as ugly and clunky. Write a web service method for each individual task you want the app to be able to perform and keep the SQL in the server. Remember to use parameterised queries and be careful of other SQL injection risks. These web service methods may use one or more queries to produce a single reply - for example, you might collect a "Customer" record and all associated "Address" and "Contact" records then return the result in a nice JSON object the Android device can consume, saving numerous slow and unreliable network round trips.
No matter what you use, make sure to do your web service calls in a background worker thread and not to block the user interface. Be prepared for timeouts and errors, and for the need for retries. Test your app by simulating intermittent connection loss, high latency, and high rates of packet loss and make sure it remains usable.
Is there a best practise:
It depends on the person. All have their strength and weakness.
I prefer, and I think many but not all will agree on JSON cause it is really easy to use in Android. It's also lightweight and very easy to use in php. Php has methods to convert an array/object to json and back.
It is indeed not recommended to save your postgres data on an android device.
My strategy is usually:
PHP server side with a POSTGRESQL database, using PDO to communicate between my models and the database.
If you are not familiar with PDO(php data objects), I recommend you make yourself familiar with it.
php.net PDO
Android as client, using JSON as method of transfering data from and to.
There are many examples that can help you.
Android has standard libraries to handle json parsing.
See this answer for an example:
example
I'm looking for some best practice concepts as far as transferring data between a mobile device (Android right now, but concepts apply pretty much to the rest as well). I currently have a WCF service set up with a working JSON endpoint. I'm starting to modify the existing service methods with the appropriate WebGet/Invokes, etc to make it RESTful. The service implements the request/response pattern so that all communication between a client and the service are wrapped in a complex MessageRequest and MessageResponse object.
What is the best way to have a mobile application successfully utilize this pattern? There are only two solutions I can come up with, each with their own pros and cons:
Create all the data transfer objects in the client project, and then create a JSON/DTO mapper (GSON might work well here). Use the client-side objects to handle all client data management until a server request is necessary, go DTO-to-JSON, and send the request to the server. The upside here strikes me is that it makes client-side data management easier because it parallels the service domain. The downside is that these have this has the potential to breakdown the more complex an object becomes.
Ignore the DTOs client side and just do everything straight from the JSON. The upside here is that it removes the overhead associated with the larger objects and the required mapping. The downside here is that this strikes me as being very brittle - any changes to the returning object need to be handled deep in the code, rather than just making the change to the client side DTO and mapper.
Is there a better way to accomplish this data exchange? Or are these the only real ways to handle it? How do you manage data transfer in your mobile applications?
I have a very similar WCF setup as you do, and I ended up creating very lightweight data objects client side. These manage pulling apart a JSONObject representing themselves and create any sub-objects they need, but aside from that are simple classes mostly used to group data together and contain no business logic. We haven't yet needed to do any client side caching, but these objects would be a great place to put in SQLite code to persist themselves out.
It has worked great so far, and we were even able to port the client-side Android code to another project running regular Java just by including org.json.