I'm looking for a way to execute "jobs" on a remote server. Normally RMI would do just fine but as far as I know, that requires an actual implementation of the logic on the server. My problem is that I can't predefine the jobs on the server because I want them to be as generic as possible.
So what I have in mind is the following: the client has the implementation of a specific job he wants to have executed. This implementation would obviously have to follow a set of rules in order for the server to be able to work with it. The client packs it into an object of some kind, sends it to the server for execution, and waits for the result of whatever computation he asked for.
Is this possible with RMI? If not, is there something else that allows me to work this way?
Thank you for your time and insight.
You can use Dynamic code downloading using Java RMI but you will have to setup a server to holds clients task classes
As I unterstand your question the server does not 'know' the code to be executed in advance.
So what you could try is sending some runtime-interpretable code like groovy, javascript or python and use one of the many interpreters out there on the serverside.
For simpler executions UEL and the concrete JUEL might be worth a look
Any object that is serializable can be passed over RMI. You could wrap the logic in a serializable object, pass that to the server, and the server executes it (it could have an execute method for example that the server calls).
As mentioned in the comments here, the class you pass from the client to the server would need to be known to both the client and the server.
Related
Is it possible that a java program is running and it works on commands from another java program simultaneously running in same machine? For example: if a second java program sends a query database command to first running java program, the first one will execute a query in the database connected to it and reply back to second one.
Please help.
Thanks in advance.
You could use socket programming to do this.
Make a server and make it listen to incoming messages.
http://docs.oracle.com/javase/tutorial/networking/sockets/
You could learn about sockets from the above link.
It is possible.
Socket programming is good but in this case you have to implement synchronization and multi threading request handling.
Another way is using web service for storing data in db.
http://docs.oracle.com/javaee/6/tutorial/doc/gijvh.html
Probably you can use any of
remote invocations (RMI), see http://docs.oracle.com/javase/tutorial/rmi/
or
manged beans (JMX), see http://docs.oracle.com/javase/tutorial/jmx/
As already answered you can use socket proramming but you would have to implement your own protocol.
It should be easier to use RMI which lets you invoke remote methods as if they were local but it is limited to java.
A "bit" heavier (in resources and implementation) solution is using web services but it is a standard which is not limited to java world.
You can also use JMS but I think it should be overkill (you need a server such as activeMQ)
I have to make an university project that involves a client/server architecture.
There should be a server where a client can login and search or save some stuff.
What's the best way to implement a stuff like that?
I think it can be done using RMI or ServerSockets or even WebServices, but what's the easiest way to implement this project?
Using Web Sevrvices i think it can be troublesome the authentication/session handling, using ServerSockets i have done some tests where i pass some custom serialized objects, but It doesnt seem to me a good way to go.
Any help is appreciated
Since this is a project for university I will not post an solution, but give you an good direction.
The most basic Way (what may be a good thing for a university project, and for understanding th whole matter...) would be with the Server listening in his Mainthread on a ServerSocket for Requests to connect to the Server and then for every (correct) Request (you need to specify somehow what is correct in this case) starting a new Thread with a Socket connected to the Client. This Threads should be hosted in some sort of List or whatever in the Mainthread of the Server...
Update:
So if this Server provides different functionalities to its clients, which are of course methods in our Server Code, you can specify the Objects which are crated when a new Client connects (I'm calling these "ClientServerConnection" from now on, and which run in its own Thread) in the Way that the Server Object is passed to it, so if one of the "ClientServerConnection"s get a Request for whatever they can call the matching method on the Server-Object and give an according response to the client...
Here some pseudo-code:
in Server:
//request for Connection came in
ClientServerConnection csc = new ClientServerConnection(this, "and everything you need, at least client IP for connecting the socket");
csc.run(); //running in its own thread, of cause ClientServerConnection should extend Thread
connectionList.add(csc); //a list of the connections the Server holds
in ClientServerConnection:
//A request to the use a functionality of the Server come in, in the easiest way you are sending a String, and than trying to match it here
if(recievedString=="doWhatever"){
Server server.doWhatever(); //calling the according method on the Server Object you passed by creation of the ClientServerConnection Object
//now return something to the client, according to whatever the Method did
}else if(recievedString=="doSomethingElse"){
//same again, according to whatever the now requested method does
}else{
//the client requested something you do not provide, need some sort of handling here
}
Hope I got you right and this helps...
'Easy' is a subjective thing, depending on what you already have experience on.
If you have experience in Java related technologies, you could pick a tech stack like Servlets, JSP and JQuery, and use GAE to keep things simple from the 'troublesome' aspects you mentioned. GAE is a platform as a service so you woudnt have to worry about those things, as google takes care of the authentication, scaling etc. You can use GAE with PHP too, if you are into that.
I think RMI is the easiest solution since you define all your interfaces and don't have to care about the protocol used to communicate.
You can also use web service with SOAP which is also a RPC (remote procedure call ) interface.
But by using Socket and ServerSocket you will learn how to build a server / client software from scratch, which is very important to know (because this is the basics).
I am creating a simulation system which consists of a test harness creating multiple processes using ProcessBuilder. I would like to be able to send multiple commands to the seperate processes, and I've only thought of a couple options - neither of which seem very fun.
The first method would be to communicate between the parent process and the subprocesses using sockets, which is how the subprocesses communicate with each other. The other would be to use the Writer method, and I've been using the Reader method to read and print the intput stream from each process. I think that both of these would require a similar level of bookkeeping. Ideally it would be nice to call a function like you would for any subclass, but I know that just isn't how multi-process works.
Please let me know what you think the best way to implement this is!
Thanks,
David
Update: I ended up creating a server socket in the test harness that communicates with all of the sub-processes. Once the system is set up, it's as simple as adding a Message to a queue, which is then sent to the correct client.
This answer is in response to your statement:
"Ideally it would be nice to call a function like you would for any
subclass, but I know that just isn't how multi-process works."
If you want to, here is how you can actually do that, if the sub-processes are Java programs running on a JVM:
Use Remote Method Invocation. The wikipedia article has a small example of an RMI server and client.
In essence this works in the following way:
A server provides some services, via remote methods, by implementing a 'remote interface' (whose definition should be available the the client also)
When the server starts up, it creates an instance of the object that implements the service, and 'binds' it to an 'RMI Registry'
A client looks up the 'RMI Registry' for a remote object which it wants to call methods on, and obtains an object which appears to implement the remote interface.
Then the client can call methods on this object, and the RMI runtime ensures that the call makes it to the remote object, and the results are returned.
This seems to be an 'official' Hello World example:
http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/hello/hello-world.html
The arguments of the call must be Serializable (so that they may be transmitted over the network). Usually, this should be as simple as appending implements Serializable to their type definition.
I wonder how can I use similar to Eclipse's remote debugging technique to get the data from remote object (that reside on server)? I am already have the client code and just want to extend it to bind (if possible) to some port and get the data from the server.
Honestly I don't want to use anything specific on the server side (i.e. create an additional code on server) because server already allows remote debugging and I can see the data in Eclipse debugger view.
If you can point me to some sample code - that would be even better. Greatly appreciate in advance.
Having read the #Romam's response to my comment, I think a better solution would be to add a simple server-side remote monitoring interface that responded to a client request, gathered the relevant object data, and returned it to the client. If the server side monitoring was compatible with JMX, you may not even need to implement any client code.
There are a number of problem with using JDPA for this, including:
Security: if the user can use your custom client to remote access your server, they can probably also use a regular remote debugger. That allows them to see any state they want to, and possibly remotely change state as well.
Complexity: driving the JDPA protocol from the client side is most likely not a simple thing to do.
Fragility: unless I'm very mistaken, your client will need to have hard-coded (e.g. in Strings) knowledge of class names, member names and member types for the server-side codebase. If you change implementation details of your server-side objects, your JDPA code may well break.
I suspect you'll find what you need here:
http://www.j2ee.me/j2se/1.3/docs/guide/jpda/architecture.html
And that you need to implement what if referred to as the 'front end' which 'implements the high-level Java Debug Interface'.
We have a string processing service (c++, uses stdin/out for in/output) that has different layouts, each layout runs separately (eventually will run on separate machines), each layout takes time to load, thats why it must keep running after first run.
I must implement a system with client that will ask the master server to connect it to a relevant slave server which actually runs the relevant layout service. The slave server will communicate the data passed from the client to the service, and when finished will become available on the master server for other clients.
The question is what is the best way to go about implementing the servers? Should I keep an open connection between slave/master until the process is complete to notify the master that the connection is over or keep some sort of var in a synchronized function to check that?
Any other important inputs (or other designs) I have overlooked are also very welcomed, Thanx!
Assuming you can't replace the C++ stuff, here is how I would do it off the top of my head.
I would setup one master server. That server would run a process that accepts requests (probably by HTTP, so it'd be a webservice) and I would have it read the request, parse out what it is, and then call the correct slave. Basically it acts as a proxy. Once it receives the response from the slave it forwards it back to the caller. The simplicity here means that if you start getting more of one type of request, you can set up additional servers for that and round-robin requests to them.
The slaves would be webservices that open the C++ program and forward input and retrieve output. That's all it would do.
I wouldn't bother keeping open connections (except between the slave and the C++ program based on your description). Just using a web request for this stuff will keep the connection between the master and the slave open during the process, but it shouldn't be a problem. This way you don't need to worry about this detail.
Now if I were you I would seriously look at reimplementing the C++ code in Java or calling it via JNI or something. If you can avoid it, I think avoiding the Java wrapper around C++ thing would be a good design goal. The Java could do whatever expensive process it is during start up once, and then hold things ready in memory like the C++ code does.
I hope this helps.
Depending on your scalability needs, you may want to take a look at the Java NIO package. This will give you a starting point to build a scalable, non-blocking server implementation.