I dont know if this question belongs to this site but, I have the following doubt, these last days I saw a lot of job proposals, that consist in Java and Flex, I dont know a thing about Java, but I wonder, is Java used for backend only? (replacing PHP i.e), or it could be used in combination with Flex in the client side?
Thanks.
We have created a fairly large application that uses Java in the server side (with most of the complicated business logic, database handling, etc...) and the client side is written in Flex.
The client side (Flex part) of the application is for presentation-only and we hardly try to keep all the business logic on the server (Java) side. Some of the reasons are:
Knowledge - where I work we are more Java developers more than Flex developers, and Java is something we handle and know better. It is faster and more secure for us to write something in Java than in Flex;
Security - keeping your business logic (and things as security, etc...) on the Java side of things will prevent someone from replacing your Flex client with some custom, malicious code and gaining access to your system when they are not supposed to.
To handle the communication between the server and the client, we use Blaze DS. It is not perfect but it is pretty good, and you can customize it to fit your needs. We have customized it so that it would accept enums, and so that we would automatically evaluate if a user was logged-in or not before invoking a Flex service on the Java side.
With Blaze DS, you can make a Java method call from the Flex side (in rough terms). Blaze DS will find the appropriate service handler for the method call you are making, and will make any data type conversions as required. Some configuration is required but once you get past the basics, it is pretty easy.
Related
I am working on an existing system written using .NET 2.0 remoting to integrate a number of embedded clients to a central server. Due to a number of issues, it has become desirable to rewrite the server in Java. Updating the clients is not really viable at this point; there are many of them and they are geographically scattered, so an update would be potentially expensive. To this end, I was wondering what solutions are available to implement a Java server that would be compatible with the existing over-the-wire protocol?
I am aware of JNBridgePro, but it is unfortunately too expensive for our current budget. I also have the CD from the book Microsoft® .NET and J2EE Interoperability Toolkit (Microsoft Press), which has a copy of a piece of software called "ja.net" from Intrinsyc Software that promises to fulfill this function, but in order to use it you need to obtain a licence from Intrinsyc and their web site is not responding (perhaps they have gone out of business since the book was published?).
Are there any others I'm not aware of?
No, no such thing (except custom commercial solutions).
However, if you are up to an in-house solution, you can:
Write your own .NET remoting adapter, which sits between the .NET clients and the Java server.
The .NET adapter translates the requests to something known by the Java server (maybe a web service interface, via SOAP) and the same for the responses.
So, the .NET adapter would be something like a pass-through and mapping component, with no actual logic. This way all logic can be in the Java server (which seems to be what you want).
It could take some time to do it, but it depends directly on the number of clients you have and on the number of types of requests and responses.
I am getting into an existing project which implies lots of remote objects communicating together to compute and transfer data.
My goal is to create a web application allowing enduser to input some data and get the results after treatment through the existing distributed application.
Regarding that, I looked for a way to make calls to existing Java objects with PHP, but in most of cases it was about how to create a JVM and instanciate objects directly in PHP, but not accessing to an existing and running JVM.
So, what could be the better way to do that ? I also heard about creating a servlet, but I have no real knowledge about this for the moment, so I am sending a S.O.S in a bottle to the StackOverflow community, hoping someone (and I am sure there is) would have a good answer to that problem :-)
Thank you for your time !
You need to modify the java application. You have to add some kind of remote interface to that app, which can then be used by PHP. If you are inexperienced in java, you're out of luck.
One of the options described above is the servlet, which basically means exposing your java app through a REST or SOAP interface. That may or may not be the simplest solution, depending on your java app. If it is a webapp, you're in luck. You can try using JAX-WS to do that. The downside is that such communication comes with an overhead. If your java app is a command line program, you could use an embedded servlet container such as Jetty or try using WSpublish (built into java 6).
You can give Hessian a try. It is a binary web service protocol that supports both PHP and java. I have used it extensively on java-only environments, but it may work in php-java scenario as well. http://hessian.caucho.com/
As you can see, there are plenty of options, but all of them require knowledge and experience in JAVA and cannot be described in one sentence or two.
The easiest java WS example I have seen can be found here:
http://java.dzone.com/articles/jax-ws-hello-world?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+javalobby/frontpage+(Javalobby+/+Java+Zone)
maybe you could try the PHP/Java Bridge project : http://php-java-bridge.sourceforge.net/pjb/
There's one door into a running java virtual machine: the java management extensions. The door has to be unlocked from the inside, so the application has to offer some managed beans and the jvm has to be started with some parameters.
But once this is setup up properly, then you have an open port where you can read and set data from/on instances or execute methods.
I can't tell exactly how difficult it is to use this connection to the jvm from "other languages", maybe you just have to be able to emulate javas object serialization with php. But it might be offer a solution for your actual problem.
I am working on a Spring web application where I have a need to interact with a remotely based command-line java application to run a simple search query on this application and get back the results. I initially had integrated this into my Spring app but my app is, itself, needing a lot of memory (its an app that involves huge amounts of data) and I don't think they can coexist on one server anymore.
I am running everything on Amazon ec2 so the latency between the servers should be really low. I figure I could use a direct SSH connection but am not so sure if this is the best approach. I'd like to keep the command-line app I am interacting with as simple as possible (would rather not make it into a web-service if I don't have to). I'm still fairly new to Java so sorry if this sounds like a basic question.
You have several options other than a web service. Some of them are:
Protocol Buffers
JMS
Simple socket based client/server Java
Thrift
Assuming you have or can have spring on both ends -
Exposing service objects and consuming them from a different process becomes extremely trivial using Spring's remoting support. (RmiServiceExporter may be most appropriate and least trivial to setup in this case)
It really does away with all the boiler plate code and let's you focus on your business/service logic.
You can write a hello world service and consume it from another Java program in less than twenty minutes. Once you have this "infrastructure" setup, you are free to focus on your actual business logic.
(You absolutely don't have to know rmi to get this working though rmi working knowledge may help if you run into problems. But then, what is SO community for? ;))
I've got a simple problem... I've got an Java applet running on my client machine which needs to communicate with a database at my end. I'm not sure how I go about it. There are numerous problems such as untrusted applet coming up. Please point me in the right direction.
Thanks in advance.
You don't want to give an applet direct access to your database, rather you want a layer of business logic in between to prevent abuse. This is known as an multitier, (aka n-tier) system. Most web apps are designed in 3 tiers:
Presentation (in your case the Java applet)
Logic (business logic handling authentication, authorization, request validation, detailed processing, etc)
Data (your trusty database)
Java applets can communicate with your server in many ways, but you'll find it easier to deal strictly with HTTP requests returning simple data structures (like JSON or simple XML, SOAP was designed to be simple but is often accepted to be anything but). This way clients can easily get through firewalls, and if you redesign your front end using flash or html5 in the future, you're back end won't need to change as much.
You'll need to decide what makes most sense for your Logic tier, as there are many options in many languages. To be consistent in language, Java servlets running on a web server (e.g. Tomcat) can provide your logic layer, and there are many tools (e.g. Spring and Guice as a framework, Hibernate and MyBatis for ORM) to make writing and maintaining servlets easier - each with their own learning curve that you'll need to decide if it has value to you.
Also don't forget to search here on StackOverflow for more explanation and alternatives - this is hardly a comprehensive answer, but hopefully a pointer in the right direction.
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.