I have a website that is a companion app for a java application. Namely, the web app fetches information from the java app and inputs it into my database and lets the user access this information. Right now I have the system set up so the Java app posts to the website's php files when I tell the Java app to.
However, I am wanting to set the system up so that the java app posts to the website when a command is issued from the website, such as a refresh command. Is this possible?
This is extremely vague. You should not think of the problem in terms of "posting from PHP to Java", in fact every HTTP request is simply that - an HTTP request. PHP and Java both offer several ways to respond to HTTP requests. It's up to you to compose the scripts that will respond to each request. Think of this in terms of the requests you need to make and the responses they should receive, then focus on writing a script for each of those interactions.
You can call Java directly from PHP. Zend Server and PHP/Java bridge both enable this. Depending on your requirements one of those may be appropriate.
Alternatively you can make use of message oriented middleware. This requires you to install and run a message broker such as RabbitMQ or ActiveMQ. However client libraries are available for much more than just PHP and Java.
Both of these would be better alternatives than relying on HTTP requests.
Related
I've been looking around all morning, and can't seem to figure this one out. I know it's not as complicated as I think it is, and all I need is just some pointers to the right direction.
I have an Android application that takes some user input, sends it to a Java application over the web, and then receives some output based on the input.
My Android and Java applications are ready, but how do I go about sending and receiving the data over the web? I understand that I'll be sending and receiving HTTP requests, but my problem is where I'll be sending them and receiving them from. Do I host my Java application on a Servlet like Tomcat, or do I use something like OpenShift to host my application for me?
I have no trouble with sending some HTTP request from my Android application to the web and receiving some output back, but my problem is that my web service needs to use a Java library to process the input and generate the output. I'm just not sure how I'm supposed to get this data to and from this Java library that needs to be hosted on the web.
I hope my question makes any sense.
EDIT: Perhaps I wasn't clear with what exactly I need help with. I do realize that the architecture I use doesn't really make any difference, but the problem I have is with how I'm supposed to use this architecture.
Let's say I have a registered domain name that I can easily send to and receive data from using my Android application - no trouble with that. But how am I supposed to integrate my Java library with this server? Do I just create an applet and put it on my server? Does my web host even allow Java applets to run?
I guess my question is how I'm supposed to get through the "barrier" between my HTTP request / transport layer protocol and my Java application.
Server architecture usually does not matter. You can use Java, NodeJs, Rails, Python, .NET, etc. You just need an endpoint that accepts a HTTP POST/PUT/GET/DELETE/PATCH verb.
This is more a question of "how do I set up a server to accept input" and its a very large topic in itself. I would advise you look at PAAS solutions like:
Parse.com
Kinvey.com
You can use their tools to build a solution fairly quickly. If you need something custom you'll need to build your backend in the language of choice and host it online via AWS, Google Cloud, Heroku, a VPS or something similar.
I'm doing performance testing for mobile application which is developed in java language and
coming to load runner scripting i'm using java over HTTP as protocol.
Actually i'm not aware of this protocol,i can able to record the application but i don't know whether all the requests got captured or not.
Note:In java over HTTP protocol no generation log and no run time viewer to validate the requests .So how can we validate?
Please share your experience on this protocol and get me out of this issue.
This appears to be a cross post with several posts on facebook. If these other posts are yours then please pick one thread as reference for answers
ShotgunPostsAreSPAM
I am currently trying to transfer a file from a Android device to a Java TCP Server, but I am unable to find a good example which explains the structure I would need to implement this. There are many Java Client&Server examples there which explain file transfer but I want to make sure if this will still work once one throws an Android Device in there.
My question is how do I implement this sort of structure? And if it doesn't work, would I be better sending the file over an HTTP connection to a PHP server? I see a lot of examples and documentation online for the later method so I presume it is more reliable. I would however prefer to use a Java server.
The file consists of a large set of coordinates recorded by the Android device which will then be sent to the server. I have not yet established how I will store this data yet but I was originally going to store them in a primitive text file.
Design
The first thing you need is something to allow you to run Java code on your server.
There are a number of options. Two of the most popular technologies are Glassfish and Apache Tomcat.
Crudely speaking Apache Tomcat is sufficient for simple client-server communication and Glassfish is used if you need to do more complex stuff. Both allow Servlets (which are essentially self contained server classes written in Java) to run on the server-side.
They handle communication with the client by launching a JVM (Java Virtual Machine) each time they receive a request. The Java servlet can run inside the JVM and respond do some processing if required before sending a response back to the client.Each new request is run in a new instance of a servlet. This makes dealing with multiple concurrent requests simpler (no need for more complex threading).
Networking (sending data to and from the server)
In networking situations the client can be a PC, an Android phone, or any other device capable of connecting to the internet. As far as the server is concerned, if the client can communicate using HTTP (a standard protocol which it understands) the it doesn't care what sort of device it is. This means that solutions for PC desktop client-server applications are similar to one for a phone.
You can use library such as Apache HTTP Components to make it easier to handle HTTP requests and responses between the device and the server. Of course you could write your own classes to do this using Sockets but this would be very time consuming, particularly if you have never done it before.
Storage of Data
If you have time I would recommend implementing some sort of database to store the information.
They have a number of benefits to such as data recovery mechanisms, indexing for fast searching of data, ensure data integrity, better structuring of data and so on.
If you decide to use a database I recommend MySQL. It is a free and more importantly - well documented.
Aside: JDBC can be used to communicate with the database with Java.
Sorry about the in-line hyperlinks - apparently my repuation isn't high enough to post more than two!
Source: Personal experience from implementing a similar design.
We have a php setup for our web pages that is secure with HTTPS. The web app talks to a DB but we also want it to talk to a java server we have.
The java server is a standalone java application (not web). We simply want a callback action after the PHP page finished writing to the DB done in the java server. What is a good way for this php page to talk to the java program to get something done?
I usually recommend against quick and dirty but here :
You can dump data in a file if it can be asynchronous. Then a cron job from java, checking for that kind of file at a regular interval, do the specified command.
For example, you can dump the word ExecuteCmd1 in a file. The java thread reads it, interprets it and choose that he must execute the method or class with the same name.
You can do the same thing over to go back to php.
Probably via a TCP/IP connection. If your Java application runs a server, then the PHP script can connect and send a message informing the Java app that the DB has been written to.
Do a quick and dirty JSON RPC from PHP to Java. You could probably get it up and running in one cup of coffee.
Use CURL on php (http://php.net/curl) and json_encode() to POST a json string to your Java server. (scroll down and find the curl wrapper class that someone wrote in the comments. It's easy.)
Use JSON (http://www.json.org/java/) in Java to decode it and use it immediately. Send your response back in JSON too.
I had a similar XML RPC system running in production for years. PHP -> IP -> Java works great.
Google Protocol Buffers Not so much dirty, but works, and works well, regardless of which launguage you use.
You can try the PHP/Java bridge. I used it a while ago to use Java logic inside Typo3, a PHP CMS.
My advice, whether you use the bridge or not: make sure you know where the errors come from if something doesn't work. Check both PHP and Java logs. Be verbose if an exception occurs.
How much data do you need to transfer?
How many requests per second?
Does the Java application have to handle the request immediately, or is it enough to handle the request in a few minutes?
Does the Java application need to return data to the user's browser?
If the answers to questions 3 and 4 are no and no, you could just create a database table for the jobs, have the PHP app insert a new job, and have the Java app poll the job table every minute or so.
I'm currently working on a project that is building a java-based desktop application to interface with a website. We want to incorporate IM capabilities, so we decided to use XMPP.
The problem is our application has other features, and anyone using another client to connect to our XMPP server will cause problems with our website (e.g. our client will be able to send our messages with a certain message type that the user won't be able to use, but with another client they could send those message types).
Is there anyone to either allow only our client to access the XMPP server or prevent other clients from using certain features? I know this is against the idea of open standards, but we don't want to build a proprietary IM solution from scratch.
You are building a proprietary solution, it just might not be completely from scratch, and that's not necessarily a bad thing. But please don't call it a XMPP service unless you are going to support XMPP clients. You will get the same reaction as you get with a "web site" that requires your proprietary browser.
For features that can be negotiated, look at Feature Negotiation and you might be able to get away with saying your server doesn't have a specific feature to other clients, but secretly supporting it in your own. That won't actually block something from being attempted, so it's pretty poor solution.
You can get instant messaging capabilities without building a desktop application (with all of the platform support headaches that entails). Consider Orbited which can give you the instant messaging interactivity your looking for and would make it much easier to integrate on the server.
And just as a side point, there shouldn't be any messages that cause problems with your web site, any more than there could be a URL that causes it problems, or a query combination, etc.
Not sure of all your requirements, but it sounds like you could probably use the pubsub or pep features of XMPP. These are extensions to XMPP that allow you to create specialized payloads that can be accessed on a user to user level (Personal Eventing Protocol XEP-0163). If it is simply a general notification to everyone who is interested, then PubSub (XEP-0060) may be what you want.
These protocols allow for securing access to the pubsub nodes and will not get affected by the standard chat messages, as they are a different protocol.