I have a java server with a BlazeDS interface to handle Adobe AIR clients. I also have a bunch of legacy stand alone java apps that I'll need to integrate with the server. The java apps need all the same methods and remote calls that the AIR clients needs. So it would save tons of work if I could call the remote object methods from the java apps.
Anyone know if this can be done?
You can use the BlazeDS Java AMF libraries directly over HTTP. But interacting with the BlazeDS MessageBrokerServlet will require some extra work. Probably an easier path is to just expose the same Java services through another protocol that the Java code can more easily use.
Take a look on this library, it allows you to connect Java with a server running BlazeDS. On the other hand if you are interested in pure performance you can investigate another protocols..there are plenty of them.
Related
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
I'm debating whether I should use java RMI or standard Java networking for an application i'm working on.
The app will be a networked system that has heartbeat sensors and failsafe-features. So it's a 3-tiered system, with at least a DB and java application.
So if my Database fails on one machine, I'd like the 2nd machine to "sense" this.
I'm a bit confused about Java RMI, whether it's worth it to learn it.
Or if I use standard Java networking , I can do the same as RMI? I mean, if I really know the Java networking well.
Thanks!
These days it is pretty easy to set up web services using SOAP or REST. With REST you can use XML or JSON messages without really having to know all about it. All these types of services can be accessed from .NET code or PHP or Javascript. (Well ... SOAP is sort of a pain except in .NET and Java. //personal opinion )
Spring can help you set up a service and a client interface to it is pretty easy. Fairly close to standard Annotations on bean classes and business methods define the interfaces and Spring does the heavy lifting. (I'm talking about Spring Web Services and not the Spring Remoting, though that would work as well. Spring Remoting isn't much better than RMI IMHO.)
You can also use Jersey (JAX-WS) or Jackson (Parse JSON) to do the remoting. Standard Annotations on bean classes and what-not build the interfaces. CXF will do JAX-WS and JAX-RS as well. Those are Java standards for building services and clients that communicate via remote messages.
Alternatively there are eclipse tools for generating both sides of the remote interface. All are tied to some framework (Axis-2 or CXS are some). Its sort of a code generation thing.
You might want to look into these a bit and see which one resonates with the way you look at things.
I know that I prefer all of these over using RMI. But I haven't used RMI directly in a long time.
RMI is higher level protocol compared to the bare TCP/IP support in Java via Socket class that you seem to refer to as "Java networking". If the only thing your system does is sending heartbeats and there are just few nodes you should choose RMI for simplicity reasons. As all of the participants are JVMs there is no need for any interop and extra libraries to support that and as the number of participants is limited there is no need to consider anything fancy.
Is it possible for a Java desktop application to interact with Java Servlets or Java EE Applications?
Yes it is definitely possible, take a look at Web Services. Here is another link with a simpler explanation.
You can also use EJBs (stateful or stateless). Installing an EJB client on your desktop app will take care of most of the communication details for you. And you always have the option of communicating via pure RMI. Both options would typically be more efficient than a SOAP or REST based solution. Good options if you don't need to worry about creating a non-java version of your desktop app.
I was looking for some opinions on the best remote method invocation practices when developing iPhone applications that communicate with Java (java EE) servers.
Many iphone applications these days typically talk to a server back end. I typically prefer to write my servers in java using some Spring libraries. So far I have not found or stuck to a definitive practice for iphone->java server communication.
What are some technical solutions and libraries that you have used to implement this kind of client-server communication?
One thing I always keep in mind is that I want the communication protocols to be simple so that multiple platforms can be added for example, in future adding Android and possibly Blackberry clients, that can use the same protocol to talk to the server.
I'd go with JSON. If you want to use Spring, go with restful webservices. Do some googling on "webservices restful spring json" (without the quotes) and you'll get some pointers.
JSON will suit you fine with other languages as well. I've written an iPhone application that uses JSON, and that was quite easy with the use of
http://code.google.com/p/json-framework. I'm pretty sure that both Android and Blackberry should be capable of reading JSON just fine as well.
Edit: I forgot to mention that I have put this iPhone application under an MIT license and you can browse the code on google code:
http://code.google.com/p/accountadmin/source/browse/#svn%2Ftrunk%2Fiphone%2FFrittRegnskap%2FClasses
I'm currently doing this for work as well. Our backend is Java EE (with Spring) and then of course the front end is iOS. We use JSON as the payload format, as Knubo suggested. All of our web services are also RESTful to make dealing with URL construction and authentication on the phone easier.
I would highly recommend you check out RestKit, which is a pretty comprehensive framework that allows you to easily integrate your RESTful, JSON-based web services with CoreData. We also use YAJL for parsing JSON manually in the rare cases where that is necessary.
Thus far, that tooling has made it a breeze to work with our web services.
http://code.google.com/p/json-framework is really useful.
To put it simple, I've written a JSE Swing app that needs to talk to a GWT server I've written earlier.
I absolutely love the way GWT does remoting between it's javascript and server sides and wish I could utilize this mechanism.
Has anyone managed to use GWT-RPC this way? Should I just go Restlet instead?
If you are doing Java-to-Java communication, RMI would be simpler and more expedient. Serializing data to/from some XML or URL-based format doesn't add a lot of value.
With EJB3, it is dead simple to deploy remote objects and to call them. You can then turn those EJBs into web services if you need to later, but for Java-to-Java, I can't think of a good reason to not use some sort of RMI-based communication.