I'm writing an application for mobile phones on Java. It's goal is to send and receive Vector objects to and from the server. But here I've got a problem: there's no ObjectOutputStream supported at J2ME.So I have to convert my Vector to byte array or do something of that kind.
I've been thinking about converting the Vector to string, transmitting it over the network and rebuilding the original vector back from the string, but it hardly seems to work in appropriate forms.
Also, I've looked at some frameworks, like J2ME Polish, but unfortunately I failed to find the jar-files with API in the installation folder.
So, any ideas?
There are two relatively easy ways to serialize and deserialize Java objects to their binary representation to facilitate network communication between a server and a Java ME device:
Protocol Buffers
Protocol Buffers are Google's creation to quickly implement very efficient exchange of data over a network. You define a "protobuf" file that is a specification of the object you want to exchange, and then the protobuf tools create client and server-side stubs to handle the serialization and de-serialization of the objects over a network connection.
Based on the "Third-Party plugin page", there are several Java ME projects for handling protocol buffers on Java ME. There are also a number of other language libraries, so this approach should give you plenty of server-side implementation options too. I personally haven't used this approach on Java ME.
Netbeans' "Mobile Client to Web Application" tools
If your server-side implementation is in Java, you can use Netbeans' "Mobile Client to Web Application" tools to generate server-side and client-side stubs to send Java objects over a binary data stream. The above link is a good tutorial for detailed implementation.
The general steps are:
a) Define your server-side web service in Java EE, including the object you'd like to pass over the network connection.
b) Run the "Mobile Client to Web Application" tool to generate client and server-side stubs.
I've used this approach in several Java ME apps and it works very well. The pros for this approach are that you can see and edit all the source code for the generated stubs, as its right there in your project. The possible con is that it requires a Java implementation of the server-side code, and isn't as portable to other platforms as protocol buffers are.
Related
I want some help on a way to transfer data from a python web application to a java desktop application.
What I am doing is having java listen on a port and receive data. But I have no idea how I would send data from python to an open port on a server.
What my question is how would I send data from a python web app to an open port on a computer. And would there be any problems like data types and any other things?
This is a really large question as there are many ways to send data back and forth between server (your java app) and client (your python app).
Your situation is not quite clear (what exactly is your "python web application"?), but you may want to look into XML-RPC. XML-RPC is extremely simple to use and set up, and takes care of "problems like data types and any other things". You basically just set up some functions on your server that the client can call, and have python call them. Arguments are neatly wrapped up by teh client and unwrapped by the server. Return values are the same. It is a simple and clean interface.
For python making calls to the server, you want to use the xmlrpclib module.
To set up an XMLRPC server in java, you have many options. I'm not a Java guy, but I'm sure it is quite simple on that side as well.
There are many good xml-rpc tutorials. Here is one that covers client and server in python.
Like I said earlier, there are MANY options available to you. XML-RPC is a good and simple way to get your feet wet, without really limiting you very much (eg: it has built in fault handling).
Good luck!
If you use a platform independent data format -- xml, json, yaml, ascii txt, ... -- to represent numbers, you have really nothing to worry about.
If you can not afford the inefficiencies of above, then a binary protocol is required.
Java uses network byte ordering (or Big Endian). Python uses the native host byte ordering, OR, you can specify the byte ordering. Here you want to specify Big Endian (sec 7.3.2.1) in writing your numeric data.
Why not use sockets in python too and send it to the java server. Java does not know that the end client is python, what it reads is just data(bytes). I have done this, and it works seamlessly.
See the python's struct module for more details on converting datatypes
What is the "official" Java API for client/server or P2P communication? Java RMI? Some other networking API??
Is this official networking API the standard for both SE and EE?
I'm sure the answer is very context-specific, so let's take a look at a few instances:
You have 2 swing clients installed on 2 machines and connected to the same network (or the Internet), and you want either of them to send the other a primitive, such as the integer 4, or some POJO, like a "Widget" object
Same as #1 above, but between a Swing client and a fully-compliant Java EE back-end (implementing managed beans, app servers, the whole nine yards)
I don't have a specific application in mind, I'm just wondering what are the "norms" for client-client and client-server communication in the world of Java.
If being bound by Java isn't a problem, RMI is a pretty abstracted solution when it comes to the client and server solution "exchanging" data (especially when the data is Java classes which might be difficult/too much effort to represent as textual data). Just make sure your object implements Serializable and almost anything can be transmitted over the wire.
If this doesn't fit your bill and you want to drop down the raw networking stuff, the client-server socket framework Netty is a pretty good choice.
There's no such thing as the most official networking API in J2SE, all J2SE APIs are official in the sense they are supported by Sun (now Oracle).
That said, you should choose your API based on following criteria:
Do you (or your team) know how to use particular API;
How simple/complex is this API to use;
What throughput are you aiming for? For performance-sensitive applications you may be forced to use binary protocol. For the rest of cases, you can use text-based protocol.
For example, between two clients simple text-based protocol will suffice for passing POJOs, for example using Apache MINA or Google protocol buffers.
This will work between client and server as well.
Response to Zac's questions in comment:
Binary protocols performance gain comes from the fact you don't need to convert everything to text form and back -- you just can pass binary presentation of you application memory with minimal changes, like, in case of BSD Sockets API, converting from host byte-order to network byte-order. Unfortunately, I don't know details about how RMI/Java serialization processes objects, but I'm sure, it still much faster than passing all data in readable form;
Yes, MINA and protocol buffers have Java APIs. They just not part of Java SE bundle, you have to download them separately. By the way, MINA can use both binary and readable serialization, depending on how you use it.
You should define notion of 'good' somehow, for example, answering to questions I mentioned above. If you want to use objects over network, use RMI. If you don't, Netty or MINA will suffice, whatever you'll find easier to master.
For P2P, Sun at one point pushed JXTA pretty hard.
I wouldn't dare to use RMI for P2P communication.
rmi is pretty much the standard java to java protocol. it's built in and very simple to use. most j2ee backends also communicate using rmi, although that's not the only possibility.
J2SE the most common is probably RMI or raw sockets.
J2EE uses a messaging bus that everyone (servers and clients) subscribes to which is quite different from rmi style solutions (although at the lowest level an implementation may still rely on RMI). It helps automate redundancy and failover. If you need this functionality I believe it can be used in SE as well.
I haven't used J2EE for quite a while now, so this may have changed, but I doubt it. The messaging system was a core component of J2EE.
What are possible options to transfer a lot of data from one computer to another not in the same LAN. The amount of data is about 100Mb unzipped and 2Mb zipped? Another requirement is that when I create a server for this (with C#) Java clients should be able to consume it.
Does WCF support something like this? But if Java clients won't be able to consume it I'm not interested.
What could be other strategies here?
I'd just use something common like HTTP or FTP, since there will be plenty of existing libraries to do it and you're pretty much guaranteed not to have compatibility problems. 2MB is not an unreasonably large amount of data for those protocols.
This is an interesting kind of question. The question is fairly simple to answer. But the interesting thing is that this kind of questions are new, they didn't exists before. Let me explain, but first I will answer your question:
You should create a server and clients both using old fashion TCP streams. To not waist bandwidth you need to compress the stream somehow, here use one of the most common compression algorithms you can find (anyone said Zip?). Now you have a language independent protocol. Clients in any language will work, mission accomplished. Also to keep it cross-platform, do not pick the best compression out there, pick the most common one (It will be good enough).
Now to why this kind of questions are interesting, they show something about OOP on the large scale. People understanding and using huge frameworks and asking if this or that framework can perform this or that simple task for them. Here we have lose our roots, we have lost the inner workings of things, it's hitting the nail not with a hammer but with a nuclear missile. It's overshooting the target, and it will produce huge applications, with huge footprint and often poor performance.
I believe that this questions has increased in number since OOP was fully adopted. It's like new programmers only want to learn these new big frameworks and that the framework dim the view of the world. There is absolutely nothing wrong with big frameworks, they are great, but I believe it's wrong to start out using them before one have mastered the basics. It's like learning to fly using a NASA space shuttle instead of a school version of a Cessna private airplane.
In C# you can serialize your object as an XML and transmit, on the other end your can deserialize your XML back to an object.
In terms of files size, you can transmit as zipped or 7z..and on the client decompress it before parsing the xml.
WCF supports SOAP and includes optional JSON serialization for XHTTP. There are other mechanisms but they are MS orientated. You will easily be able to consume the service you create. However you will have to consider how to encode the data as it will hit the wire in a non binary data friendly manner (XML/JSON).
You may wish to instead create a simple http handler that can return the data directly as zip using appropriate mime headers etc. You should then be able to just hit that using your Java client.
XMPP is another option. You need another server, but this could be an advantage: the client wouldn't need to know the servers IP address, server and clients would simply connect to the XMPP server to exchange message and files.
Related links (for Java):
Openfire XMPP server
XMPP library for java (Smack)
You didn't mentioned what type of data do you want to send. So for keeping things simple I will suppose that you have data stream which can be converted to byte array. Content of the stream has to be in format which is understandable to both C# and Java!
The best choice is to compress your data stream with GZip stream. Gzip should be supported on Java. Than you can send that stream converted to byte array as response from your WCF service operation. You can use default text encoding which will convert byte array into Base64 encoded string. If your java client supports MTOM (it is standard which is supported by Java) than you can use MTOM encoding which uses smaller messages.
If you don't have a stream with well known content format you have some sort of custom data. For custom data you have to use interoperable transport format which is XML. Using XML will futher increase size of your data. In that case you should consider dividing your data transfer into several calls. You can also try to host your WCF service in IIS 7.x and take advantage of its build in feature - compression of dynamic content. If your Java client calls the service with HTTP Accept-Encoding header set to compress, gzip it will automatically compress the response. Be aware that only .NET 4.0 WCF clients can work with such service.
I would like to ask for some ideas regarding a scenario like this:
1) we need to build up a real time application that runs on a client. Some sort of stock trading functionality, updates pushed to few clients in different geo locations every 25 secs.
2) the data is collected and pre-processed on the server side (Glassfish/Java)
We have been discussing options and narrowed down 2 options:
1) WPF on the client
2) Swing (we previously evaluated JavaFX)
What are your thoughts on:
1) easiness/speed of development of an "medium" complex client application in Swing vs. WPF
2) communication between WPF and an app server. If we would have a monolithic solution (Java), there are more options for hight throughput data exchange like Java Messaging, without going through some .NET to Java bridges or sending data across via XML, webservices etc.
Any thoughts welcome.
Thank you
Swing vs WPF
I've done extensive work using both Swing and WPF. Swing is at least a whole generation behind WPF. There really is no comparison. WPF's data binding and templates make all the difference. You will save a lot of time and money, and end up with a much better user experience if you use WPF.
NET Framework connection to Java back end
Regarding using NET Framework on the front end against a Java back end: It is extremely easy to do and will generally perform as well as a pure Java solution. The exception would be if your main bottleneck is network bandwidth and you are serializing complex trees of objects.
As itowlson noted, WCF doesn't talk Java's proprietary binary protocols, but there are still a lot of choices that can be used to talk to Java: XML, JSON, text (REST). I generally recommend good old-fashioned XML Web Services. It takes about two minutes to set up WCF to talk to a simple Java web service.
XML Serialization typically only adds 5-10% to network bandwidth over binary, so unless you have a lot of complex data and your pipe is very tight, I would just use WPF/WCF talking directly to Java on the back end. If you do have lots of data and a tiny pipe, you still want the WPF front end because it is so much better than Swing, but you might consider using the WCF binary formatter over the wire and doing the conversion on the server.
Regarding communication between WPF and an application server, you can use all of .NET's messaging facilities, specifically including Windows Communication Foundation. However, WCF does not have out-of-the-box support for binary messaging to Java (see Does WCF play well with Java? for discouraging info) so you would need to use XML, a custom transport that could be supported on both ends (such as MQ) or a bridge.
(Can't help with the comparison of WPF vs. Swing, as I have no experience of Swing.)
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...]