We've got a server app and two stand alone client apps (both with different functionality - one for front office and the other for back office). Everything is written in Java.
What we need right now:
If both apps are running - click on a button in one app -> checks to see if the other app is open and triggers some functionality (display a message, open a frame) on that app
if the other app isn't open -> it should display a message saying so.
Can anyone point me in the right direction to achieve this. The best real life example I can give is: how clicking on the an itunes link in the web browser opens the iTunes application if installed and to the relevant appstore page.
EDIT: Our applications don't deal with websites at all. Everything uses Swing.
There is no "best" way to achieve inter-app communications but there are many ways; the best one will be the one that fits best your environment: network conditions, firewalls, number of calls, synchronous vs asynchronous, etc...
Usually communication is achieved using either:
Remote Procedure Calls: an app basically calls a function/method on the other app and passes arguments. RPC are usually synchronous: the response is sent within the same communication/transaction
Messaging: an app sends messages to the other app which, maybe, replies with other messages. Messaging is usually asynchronous.
The frontier between the two can be pretty blur with some protocols like REST.
In the Java world,
RPC is usually achieved using either
RMI: Java only solution; easy to implement; does not like firwalls much.
SOAP Web services: not Java centric; hard to implement; full of traps; network friendly.
Messaging can be achieved using
JMS: Java only; rather easy to implement but asynchronous; extremely powerful on high loads
JSON/XML HTTP/s Messaging: there are many protocols here from the most secure like AS2 to RNIF, plain XML/Json POST etc... These are network and language agnostic but always require some work to implement.
An hybrid approach is REST which has become very popular due to the benefits of an easy implementation and network friendliness but has the drawbacks of not being very formalized. it is a technology rather than a specification. I would look at documentation around JAX-RS and frameworks like Restlet and Jersey to get you started.
(Edit)
I purposely did not mention developing your own with Java sockets. IO is by definition impure and often multithreaded: IO is very hard to get right. If you really insist going down that route, at least, use the help of a proper framework like Apache Mina or Netty.
I am trying to set up a webserver on an old machine of mine. I have installed ubuntu server edition and aim to use it for the following:
I want to run a java program on the server. I want to be able to retrieve data from the program from another computer/phone using an internet connection. I also want to be able to give the program data, and get a response saying whether or not the data has been received correctly.
So for example:
A .jar program runs on my server and holds a variable x
I want to be able to query the value of x from another device (over the internet).
I want to be able to set the value of x remotely from another device, and get a response saying it was successful in altering the value.
What are my options here? I would like to try and keep things simple. It is perhaps worth mentioning that I will be the only one using the system. The server will be used exclusively for dealing with the two requests outline above.
Is it simply the case of creating a java program that listens out for incoming requests and running that on the server?
As you mentioned, you can start with custom ServerSocket wrapper which will decode incoming requests and do as it's bid. Currently, whole frameworks are done to encapsulate common code of this task -- see my 3rd point.
Old-school java solution: use RMI. See RMI tutorial.
New-school java solution: devise some simple text-based protocol with 2 commands:
Read()
Set(newVal)
Then implement that protocol over some new trendy Java framework, like Apache MINA, which is created specifically to facilitate quick development of network apps in Java.
I, personally, started with RMI for such kind of tasks. Since RMI is considered Core Java technology, it's wise to learn it.
Now there is a new requirement. I have got some adhoc work at hand. The requirement is to connect a desktop based Java application to read data from Mainframe generated by some CICS Transaction. [Basically I have to read all the records being appended into a file (same way as we do tail-f filename in linux). This is just for FYI my requirement is something different.]
I inquired, and came to know that my employer cannot provide MQ or CICS Transaction Gateway access to me. He suggested some method of screen scraping. I have already done that using VB.Net application and Quick3270 as well as IBM Communicator Emulators. Both these emulators provide functions which can be used to read whatever is there on the screen.
You can refer to EHILLAPI programming details (Language for Emulator programming) - http://publib.boulder.ibm.com/infocenter/pcomhelp/v5r9/index.jsp?topic=/com.ibm.pcomm.doc/books/html/emulator_programming07.htm if you are interested in learning.
But this method is restricting me to the maximum number of bytes that can come on the screen. With this method there is significant network delay as I have to refresh (basically move from one page to another on CICS) everytime to get data which is spanning across multiple pages.
Can you suggest me some method so that the my employer does not need to ask the client to open any port on his Mainframe or install any software (as this is not possible for my employer).
Can I use the 3270 terminal emulation and retrieve all (or at least more data). This way the requirement of my employer is fulfilled and he does not need to ask anything to his client. (In any case from the emulator we are firing CICS Transactions). We want everything to be done at my employer's end itself without disturbing the client's Mainframe even a single bit.
Please do not suggest MQ as the client does not have it.
If you are still suggesting CICS Transaction Gateway, then please let me know how would I connect to the remote machine (I need technical details).
- What information do I need to ask from the client.
- What software do I need to install on my machine.
- Technical details of using that software.
Regards,
Nitin
I have two suggestions for you to look at. I have done both successfully. Your client setup can decide if either is palatable (the question doesn't mention not doing these things).
You can call your CICS code on the mainframe via a DB2 stored procedure. There is a standard one supplied by IBM called EXECCICS that we used for a project. You supply the standard CICS parameters and comm area. The stored procedure executes the program in the mainframe and returns you the comm area. You use JDBC. This solution is simple and easy the execute.
We have also enabled HTTP access to the CICS program on the mainframe. To my understanding (remember I just called it -- not enabled it) it is a pretty standard configuration. The client code just performs an HTTP POST to a specific end point. The resulting document is the comm area plus other goodies.
These solutions were developed independently for the same project and are both in production. The only reason the HTTP method was added to the mix was because of a data size limit in the stored procedure that HTTP removed.
I'm writing a Java application that will run for a long time (essentially, it stays running between system restarts) and does a fair bit of intensive near real-time data processing. Data is delivered to the application, some work is done on that data, and it's then passed on for delivery.
I need to provide a way to inspect the inner workings of the application at runtime. I've already got a fairly well established but hand-carved telnet style interface that allows you to use a command line to ask questions about statistics, data queues, etc, but I'd like to move that to HTTP as I think it will allow me to provide a much richer picture of what's going on (showing load graphs, etc).
Are there any established Java frameworks that allow me to embed a web server and handle requests in a reasonable way? I don't really want to have to hand-carve a whole lot of HTML handling and response generation as it's just annoying background noise to the essence of what I need.
Are you sure you want to embed an HTTP interface?
A pretty common way of doing things like this is to set the Java application up with a restricted RMI interface. Then, you write a J2EE (JSP/Servlet) web interface which makes RMI calls to the application for data.
This setup avoids you having to implement the HTTP protocol (or any other interface protocol - RMI calls are just Java methods), and also separates data (the embedded J2SE program) from presentation (the user-interface J2EE program).
You may want to consider using jconsole and JMX (http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html).
They provide a graphical way to see what is going on inside your application and you can also setup controls to perform given actions through jconsole.
I am implementing a website using PHP for the front end and a Java service as the back end. The two parts are as follows:
PHP front end listens to http requests and interacts with the database.
The Java back end run continuously and responds to calls from the front end.
More specifically, the back end is a daemon that connects and maintain the link to several IM services (AOL, MSN, Yahoo, Jabber...).
Both of the layers will be deployed on the same system (a CentOS box, I suppose) and introducing a middle layer (for instance: using XML-RPC) will reduce the performance (the resource is also rather limited).
Question: Is there a way to link the two layers directly? (no more web services in between)
Since this is communication between two separate running processes, a "direct" call (as in JNI) is not possible. The easiest ways to do such interprocess communcation are probably named pipes and network sockets. In both cases, you'll have to define a communication protocol and implement it on both sides. Using a standard protocol such as XML-RPC makes this easier, but is not strictly necessary.
There are generally four patterns for application integration:
via Filesystem, ie. one producers writes data to a directory monitored by the consumer
via Database, ie. two applications share a schema or table and use it to swap data
via RMI/RPC/web service/any blocking, sync call from one app to another. For PHP to Java you can pick from the various integration libraries listed above, or use some web services standards like SOAP.
via messaging/any non-blocking, async operation where one app sends a message to another app.
Each of these patterns has pros and cons, but a good rule of thumb is to pick the one with the loosest coupling that you can get away with. For example, if you selected #4 your Java app could crash without also taking down your PHP app.
I'd suggest before looking at specific libraries or technologies listed in the answers here that you pick the right pattern for you, then investigate your specific options.
I have tried PHP-Java bridge(php-java-bridge.sourceforge.net/pjb/) and it works quite well. Basically, we need to run a jar file (JavaBridge.jar) which listens on port(there are several options available like Local socket, 8080 port and so on). Your java class files must be availabe to the JavaBridge in the classpath. You need to include a file Java.inc in your php and you can access the Java classes.
Sure, there are lots of ways, but you said about the limited resource...
IMHO define your own lightweight RPC-like protocol and use sockets on TCP/IP to communicate. Actually in this case there's no need to use full advantages of RPC etc... You need only to define API for this particular case and implement it on both sides. In this case you can serialize your packets to quite small. You can even assign a kind of GUIDs to your remote methods and use them to save the traffic and speed-up your intercommunication.
The advantage of sockets usage is that your solution will be pretty scalable.
You could try the PHP/Java integration.
Also, if the communication is one-way (something like "sendmail for IM"), you could write out the PHP requests to a file and monitor that in your Java app.
I was also faced with this problem recently. The Resin solution above is actually a complete re-write of PHP in Java along the lines of JRuby, Jython and Rhino. It is called Quercus. But I'm guessing for you as it was for me, tossing out your Apache/PHP setup isn't really an option.
And there are more problems with Quercus besides: the free version is GPL, which is tricky if you're developing commercial software (though not as tricky as Resin would like you to believe (but IANAL)) and on top of that the free version doesn't support compiling to byte code, so its basically an interpreter written in Java.
What I decided on in the end was to just exchange simple messages over HTTP. I used PHP's json_encode()/json_decode() and Java's json-lib to encode the messages in JSON (simple, text-based, good match for data model).
Another interesting and light-weight option would be to have Java generate PHP code and then use PHP include() directive to fetch that over HTTP and execute it. I haven't tried this though.
If its the actual HTTP calls you're concerned about (for performance), neither of these solutions will help there. All I can say is that I haven't had problems with the PHP and Java on the same LAN. My feeling is that it won't be a problem for the vast majority of applications as long as you keep your RPC calls fairly course-grained (which you really should do anyway).
Sorry, this is a bit of a quick answer but: i heard the Resin app server has support for integrating java and PHP.
They claim they can smash php and java together: http://www.caucho.com/resin-3.0/quercus/
I've used resin for serving J2ee applications, but not for its PHP support.
I'd be interested to hear of such adventures.
Why not use web service?
Make a Java layer and put a ws access(Axis, SpringWS, etc...) and the Php access the Java layer using one ws client.
I think it's simple and useful.
I've come across this page which introduces a means to link the two layers. However, it still requires a middle layer (TCP/IP). Moreover, other services may exploit the Java service as well because it accepts all incoming connections.
http://www.devx.com/Java/Article/20509
[Researching...]