Embedded Web Service on Android device - java

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.

Related

LDAP Server front-end Java library

I've been asked to look into adding an LDAP interface to an existing Java web application - that is, to make it possible for LDAP clients to connect to the application as if it's an LDAP server. I could write code to listen on a dedicated port and implement the LDAP protocol, and hook that into the existing database... but I'd have to understand the protocol first and then there are potential security issues if I write that from the ground up (not to mention the time it could take).
What I'm looking for is a library of existing code - something that handles the ports and protocols, and lets me focus on writing just the back end. There are plenty of client-side libraries out there, as you'd expect, but I've had no luck in finding something to help with server-side development. So the question is, does anyone here know of such a library that would help with this?
Yes you will most probably find many more client implementations than server, however LDAP is a request response protocol, so with a bit of playing around you should be able to use the same classes and their serialization capabilities. Instead of sending the request you would be receiving it, and responding with the response you would otherwise expect from the client.
You could look at the Apache Directory. https://directory.apache.org/api/
It has an embedded directory server project as part of it, which claims to be extensible and embeddable in your application. https://directory.apache.org/apacheds/
So maybe that could be the answer to your needs.

Wish to create desktop app that combines facebook and email accounts all in one go - stuck at the first hurdle?

first poster :)
As the title says, I am looking to create a desktop app which will notify me of changes on facebook and new emails, and the facebook part (the first part I've tried) is baffling me. I've never worked with an api before, and have no idea how to integrate facebook's api with this desktop helper I want to create. I will be using java to create this desktop helper.
Thanks in advance!
Here are few pointers for you to get started. Please feel free to ask for clarifications and I will edit my answer accordingly:
For facebook, you can actually pull all those info via their API. There are a lot of types for API, but Facebook specifically use REST API over http.
To simplify, think of it as making an http call with specific parameters and you will be getting an output back.
In order to use facebook API you need to understand their protocol including authentication/login and how to request for things that you want. This would require some reading to their documentation which is pretty complete and available at http://developers.facebook.com/docs/.
For the description of their API URL and the input/output documentation, you could directly jump to Graph API Documentation http://developers.facebook.com/docs/reference/api/.
In order to call their API via HTTP from Java, you could leverage HttpClient library from Apache Http Components project http://hc.apache.org/. They have plenty of tutorial and examples for how to make http call using HttpClient
For combining with all other emails accounts (per your question), you need to deal with SMTP or IMAP (whichever email protocol that you are planning to combine with Facebook). This is already built-in to Java via their Java Mail API collection
You then can poll this data on interval basis to get an update from Facebook and your mails
Once you have figured out how to get the data, the rest is just following a good MVC framework. That means separating out your presentation, data and controller (application logic). Make sure that you are separating the classes for #1 and #2 and each of them put their data to normalized data format that then get feed to your View (presentation layer)

Client or server side invocation to google API?

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.

Java HTTP Proxy

I am working on a project where we'd like to pull content from one of our legacy applications, BUT, we'd like to avoid showing the "waiting for www.somehostname.com/someproduct/..." to the user.
We can easily add another domain that points to the same server, but we still have the problem of the someproduct context root in the url. Simply changing the context root is not an option since there are hundreds of hard coded bits in the legacy app that refer to the existing context root.
What I'd like to do is be able to send a request to a different context root (Say /foo/bar.do), and have it actually go to /someproduct/bar.do, (but without a redirect, so the browser still shows /foo/bar.do).
I've found a few URL rewriting options that do something similar, but so far they seem to all be restricted to catching/forwarding requests only to/from the same context root.
Is there any project out there that handles this type of thing? We are using weblogic 10.3 (on legacy app it is weblogic 8). Ideally we could host this as part of the new app, but if we had to, we could also add something to the old app.
Or, is there some completely different solution that would work better that we haven't though of?
Update: I should mention that we already originally suggested using apace with mod_rewrite or something similar, but management/hosting are giving the thumbs down to this solution. :/
Update 2 More information:
The places where the user is able to see the old url / context root have to do with pages/workflows that are loaded from the old app into an iframe in the new app.
So there is really nothing special about the communication between the two apps that client could see, it's plain old HTTPS handled by the browser.
I think you should be able to do this using a fairly simple custom servlet.
At a high level, you'd:
Map the servlet to a mapping like /foo/*
In the servlet's implementation, simply take the request's pathInfo, and use that to make a request to the legacy site (using HttpUrlConnection or the Apache Commons equivalent).
Pipe the response to the client (some processing may be necessary to handle the headers).
Why not front weblogic with Apache.
This is a very standard setup and will bring lots of other advantages also. URL rewriting in apache is extremely well supported and the documentation is excellent.
Don't be put off by the setup it's fairly simple and you can run apache on the same box if necessary.
Using Restlet would allow you to do this. The Redirector object can be used. See here and here for example.
If you instead serve out a JSP page you can use the tag to do the request server side.
Then the user will not even know that the resource was external.
http://java.sun.com/products/jsp/syntax/1.2/syntaxref1214.html
a bit more context for the API the client is working against would help here to give a solution that could work. Are you trying to provide a complete new API totally different from the legacy Java EE app? What artifact is serving the API (Servlet, EJB, REST service)?
If you have the API provided by a different enterprise application then I suppose you simply use a Pojo class to work as a gateway to the legacy app wich of cause can then be reachable via another context root than the new service app. This solution would assume you know all legacy API methods and can map them to the calls for the new API.
For a generic solution where you don't have to worry about what methods are called. I am curious if the proxy approach could really work. Would the user credentials also be served correctly to the legacy system by URL re-writing? Would you have to switch to a different user for the legacy calls instead of using the origin caller? Is that possible with URL re-writing. Not sure if that could work in a secure context.
Maybe you can provide a bit more information here.

Creating a REST webserver with security

I am very new to creating webservers - and I have had several goes at trying to understand them and write a quick webserver, but it's never quite 'clicked'. At the moment I am under the impression that REST would be most suitable for my purposes (I will explain later).
Can anyone either show me a basic code example in Java (using Tomcat Apache) or a tutorial resource to show how a webserver:
Can be used for security - i.e. pass in some kind of value to identify the client - from their the webserver will either deny or grant access to the client dependant on some criteria - maybe a lookup list.
Once the client is successfully accepted they will be allowed to pass in some more values to the webserver that will be used to write a row in a database table.
Many thanks.
PS - I would have thought there might have been soemthing that comes with Eclipse Ganymede? If someone can confirm?
The best way to write restful resources in Java is via the JAX-RS standard. So I'd recommend you download Jersey which is the JAX-RS reference implementation and check out its examples; its got lots of them. Take an example for a spin then try hacking it to do what you like.
BTW JAX-RS can be run inside any Servlet engine - you just build a WAR and deploy it (there are examples in the Jersery samples) - though Jersey also comes with a small lightweight web server you can use too which is a little easier to use - again there are examples in the distro of this.
I would also suggest that you look at Restlet

Categories