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...]
Related
Firstly Cheers to all PROGRAMMERS [ Today = Programmers day :) ]
Secondly,
I'm working on a project where the specifications require using a server as a front end and an application in the back end. The project is an advanced smart home system. The server will handle commands coming from the client through the internet (let's say like a remote control from outside the house) and send them (through a channel of communication) to the application (planning on using JAVA application) which will handle the main logic like controlling hardware stuff (lights ...) , reading from a microphone (local mic) and accessing a database to act as a speech recognition system (offline).
Now I'm still in the planning phase and I'm not sure which technologies are the best for this project. I'm thinking to use Node.js or Apache as the server and a JAVA application as the back end and any SQL database for the application's SRS.
I hope this illustration demonstrates clearly how the system works:
The main question is:
What is the best way to make the Java application communicate with the server (communication channel [must be bidirectional]) ?
and Do you recommend a specific server other than the mentioned ones for this job ?
What crossed my mind so far:
1- JSP and servlets (making the server is the application too). But I don't want a server to handle the offline stuff and I'm not sure if java servlets can access hardware interface. I also want the server to be separate from making critical decisions (different layer for security reasons and since it won't be used as frequently as the local [offline] system).
2- Communication channel :
A- A shared file, but it's a bad idea since I don't want the application to check if the file contents changed (command received) or not from time to time (excessive operations).
B- A an inter-process-communication through a port (socket communication) seems the best solution but I don't know how that would turn in terms of operation cost and communication errors.
OS used : Linux Raspbian
EDIT:
I'm sure ZMQ+Apache is good enough for this task, but how is it in comparison to WebServices (like SOAP) ? Would WebServices be a better solution in terms of standard implementation and security ?
All related suggestions are welcomed, TQ
ZeroMQ is great for internal communications, or any other similar communication solutions.
For specifically your case, I can see that ZeroMQ would be a best fit.
Reasons:
You offline server have to be agnostic to web solution.
Communication can be reliable and bi-directional, possibly another patterns like (pub>sub, req<>res, etc).
Restarting any of sides would not require to restart the sockets (connection) on other side, as messages are queued.
Possibility to scale not just on same hardware, but as well to local area network or even through internet.
Big community of support. It might look a bit hard to get into, but in reality it is dead simple, just go to examples and once concept understood - it is very easy and neat to work with.
ZeroMQ has lots drivers for most popular languages, that includes Java and Node.js.
Considerations:
You need to think over packets and data will be sent. So some popular data protocols like XML or JSON is good way of thinking.
Responsibilities over different services - make sure they are not dependant on each other too much. Or if main offline server - is a core of system, make sure it does not depend on web facing service, so that web face can be removed/replaced/improved etc.
Few more points to think about:
Why Java, and what about modular approach? For example if you want to expand and scale - add more sensors into smart home solutions, then having one giant application would require to change it, it is harder to maintain as well as maintain different clients with own needs. Think modular way - some core functionality for offline stuff, but many aggregator processes that would talk to different sensors. This makes easier to support different setups and environments, as well maintain the system as a whole by improving independent components.
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'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.
Suppose i have one website with simple pages in php like
page1.php
page2.php
Now there is one page where i want some detailed functioning and i want to use python for that and it will look like
page3.py
and in other page i want to use java like
page4.jsp
Provided i have installed python , java on webserver.
Is it possible?
Yes. It's possible. Where you will find yourself in trouble is when you want to share server-side information among them (I.E. sessions).
Other than that, you can use (but I would advise against it) all languages you want on a website.
Yes, it is possible, but you definitely should NOT do it.
Communication between pages running different technologies will not be elegant, if for no other reason than the fact that you won't get a shared session pool. Session bridges are possible, but they are a pain to do.
I would say you are making a mistake if you can't just pick a single language for your core web layer.
Yes it is very possible, as long as the server can serve the files you want to use. If it doesn't have python, you can't use python.
It depends on the web server. Apache can do it. Just make sure you have the appropriate handler modules for each file type, and use the AddHandler configuration directive to map each type to the appropriate handler.
Also, to be pedantic, you can not only use all three of those, but you can actually integrate them at the session level, since all of those languages are available on the JVM. So, in one container you can run all of the PHP, Python, and Java code. You can share session state, reuse connections to the database (via server wide connection pools), leverage Java libs in your PHP and/or Python code, etc.
I'm not saying this will be "drag and drop" easy, but it is possible, and even practical if you need that kind of close integration (vs integration via a database or filesystem). There will likely be nuances in ensuring that the Python and PHP code runs properly on the Java implementations as well.
Short answer: Yes, many web servers can handle generating pages from multiple languages.
People are talking about session...
Almost all server side technologies today support custom session providers, where you can hook up some code to share you session between different HTTP modules and binders.
If you are starting to write a web site from scratch, and you need to write all of your code for yourself, than probably you will choose to do it in one programming language (only for your comfort of coding).
But... where it's all starting to change? When you want to mash-up some open source and community source code to make a web site. Let's say a store & community with ASP.NET to mix up with CRM like Sugar CRM (which is in PHP).
In that case you don't need any session sharing, just users sync procedure in the DB.
Also, if you choose IIS 7 (Windows Server) or Apache (using Mono project you can run ASP.NET on LAMP), you could run them both on the same machine.
And remember, the most important thing is TIME TO MARKET! So saving code time can be crucial for you success.
ENJOY!
I work for a PHP development company and all the time these ASP.Net companies come to US for whatever reason I've never understood. We build them forms in PHP usually dynamically pulling in the layout - sometimes hosted on a subdomain, sometimes hosted directly in IIS with the PHP module. Its very messy and bad, it can be done but I'd say avoid it.
You can use Apache Reverse Proxy to do it and session must be readable between programming languages. I use Go, NodeJS and PHP in one website. Session is saved in Postgresql. The hardest part is all programming that is used in your website can read session with same format and saved in same place. I have used github.com/yvasiyarov/php_session_decoder to read and save session with Go and save it in Postgresql so PHP can process that session
I have a really simple Java class that effectively decorates a Map with input validation, with the obvious void set() and String get() methods.
I'd like to be able to effectively call those methods and handle return values and exceptions from outside the JVM, but still on the same machine Update: the caller I have in mind is not another JVM; thanks #Dave Ray
My implementation considerations are typical
performance
ease of implementation and maintenance (simplicity?)
reliability
flexibility (i.e. can I call from a remote machine, etc.)
Is there a 'right way?' If not, what are my options, and what are the pro/cons for each?
(Stuff people have actually done and can provide real-life feedback on would be great!)
Ok. Here's another try now that I know the client is not Java. Since you want out-of-process access and possibly remote machine access, I don't think JNI is what you want since that's strictly in-process (and a total hassle). Here are some other options:
Raw Sockets : just set up a listener socket in Java and accept connections. When you get a connection read the request and send back a response. Almost every language can use sockets so this is a pretty universal solution. However, you'll have to define your own marshalling scheme, parsing, etc.
XML-RPC : this isn't as hip these days, but it's simple and effective. There are Java libraries as well as libraries in most other languages.
CORBA : as mentioned above, CORBA is an option, but it's pretty complicated and experts are getting harder to come by.
Web Server : set up an embedded web server in your app and handle reqests. I've heard good things about Jetty or you can use the one provided with Java. I've used the latter successfully to server KML files to Google Earth from a simulation written in Java. Most other languages have libraries for making HTTP requests. How you encode the data (XML, text, etc) is up to you.
Web Services : This would be more complicated I think, but you could use JAX-WS to expose you objects as web services. NetBeans has pretty nice tools for building Web Services, but this may be overkill.
Will you be calling from another JVM-based system, or is the client language arbitrary? If you're calling from another JVM, one of the simplest approaches is to expose your object as an MBean through JMX. The canonical Hello World MBean is shown here. The pros are:
Really easy to implement
Really easy to call from other JVMs
Support for remote machines
jconsole allows you to manually test your MBean without writing a client
Cons:
Client has to be on a JVM (I think)
Not great for more complicated data structures and interactions. For example, I don't think an MBean can return a reference to another MBean. It will serialize and return a copy.
Since your callers are not Java apps and you're already foreseeing networked callers, RMI-IIOP (CORBA) might be an option. Though it's definitely not easy to implement, it has the advantage of being a widely-recognized standard.
Since your caller is not JVM-based, this is a question of inter-process communication with JVM. The options I have in mind are:
Communicate over a socket: make your JVM listen to incoming connections and caller send commands
Communicate using shared files (caller writes to file, JVM polls and updates)
Using JNI, start JVM inside a callers process and then use RMI/MBeans to communicate with the first ("server") JVM. Caller will have access to results using JNI
Option 3 IMO is the most "Java" way of doing this, and is the most complex/error-prone.
Option 2 is ugly but simple
Option 1 is moderately easy (java part) and otherwise ok.
For ease of use, I would use Spring Remoting. If you are already using Spring in your project, that's a no brainer. If you arent ... well you should have a look anyway.
Spring provides an abstraction that allow you to switch remoting protocols easily. It supports the most widely deployed protocols (SOAP, Hessian, Burlap, RMI, ...). If you are calling from non Java code, Hessian has support in a number of other languages, is known to be more efficient than SOAP and easier than CORBA.
Beanshell is a shell-like java interpreter that can be exposed over a network socket. Basically you do this from java:
i = new bsh.Interpreter();
i.set( "myapp", this ); // Provide a reference to your app
i.eval("server(7000)");
and then you do this from anywhere else:
telnet localhost 7001
myapp.someMethod();
This little utility does remote java invocations much more easily than JNI or RMI ever has.
For more, start at: http://www.beanshell.org/manual/remotemode.html
JNI (Java Native Interface) allows access to java code from C or C++.
I have an Inno Setup script (installing a Java program) which calls some Java methods to perform some operations or check some conditions.
I (actually my predecessor) just instanciate java.exe on each call. Which is, obviously, costly, although not critical in my case (and the Windows cache kicks in, I suppose).
An alternative is to use some inter-language communication/messaging, your Java program acting as a server. Corba comes to mind, as it is language agnostic. But a bit heavy, perhaps. You can use sockets. RPC is another buzzword too, but I haven't much experience in the field.
What you want is the Java Native Interface (JNI), despite the difficulties that it may present. There is no other equivalent technology that will be as easy to implement.
As mentioned in the comments for the preceding answer, the JNI is optimized for calling native code from Java, but it can also be used for the reverse with a little work. In your native code you'll need to implement the JNI entry point--something like SetMapPointer()--then call that function from the Java code once the Map is built. The implementation of SetMapPointer() should save the Java object pointer someplace accessible, then the native code can invoke Java methods on it as needed.
You'll need to make sure that this happens in the right order (i.e. the native code doesn't try to access the Map before it's been built and passed to native code), but that shouldn't be an especially hard problem.
Another alternative to consider if the other process will be on the same machine and the OS is POSIX-compliant (not Windows) is Named Pipes.
The outside process writes the operations, as strings or some other agreed-upon byte encoding, to the named pipe while the Java application is reading from the pipe, parsing up the incoming operations and executing them against your object.
This is the same strategy that you would use for socket connections, just instead of a SocketInputStream you'd be reading from a FileInputStream that is attached to a named pipe.
An alternative to CORBA is ICE, unless the licence is a problem (it's GPL, but you can also buy a commercial licence).
It has pretty much all the benefits of CORBA, but ZeroC, the vendor, provides bindings for many different languages. CORBA vendors tend to only provide one or two language bindings, and then you start finding compatibility problems.
The documentation is also excellent. I wouldn't have said it was particularly easy to pick up, but probably easier than CORBA.
Otherwise, another option I don't think has been mentioned is the new middleware/RPC framework developed by Cisco, now donated to Apache, called Etch. It's still pretty new though, and documentation is sparse.