I wanna do a service that distributs tasks amongst several servers, which execute those tasks.
To do that, I made use of the Java RMI technology and all works just fine, but it is a mess. I have a big class, which is
mixed with remote methods which are called by the servers to post messages and client methods
to schedule tasks to the service which are called by the client.
I am now trying to find a proper solution to encapsulate the remote methods from the business methods, but struggle as they are thighly coupled. The message implementation (see the example class diagramm) interacts thightly with the private business methods.
This might also include invoking events which the Client class
subscribed. My first thought was the approach with a message handler. But how can the message handler still interact with private methods of the server and invoke events on the service.
I like to ask you if you have any idea for my problem. How can I encapsulte the remote interface and its methods from the non remote methods?
If I understand the problem correctly, you have a big class with three kinds of method:-
Remote methods intended for use by the client, but not by the server;
Remote methods intended for use by the server, but not by the client; and
Local methods not intended to be remote at all.
It seems to me that creating two remote interfaces (one for the client, one for the server) and implementing them both in the big class will do what you want. The client will only see one interface and the methods in it; similarly for the task server.
Is that enough encapsulation? Or did you mean something more?
Related
I'm writing a server-client architecture based game in Java.
For design reasons, I would like to use asynchronous calls for passing client actions to the server, and also asynchronous callbacks for passing the result(s) of said actions back to the client. Asynchronous calls allow buffering of client actions. Queued buffering allows simple, basically one threaded processing of client actions.
At the moment, my server and client code is pretty symmetric. They create a registry, then export and bind themselves.
Asynchronicity is achieved by buffering the incoming actions or results in a ConcurrentLinkedQueue. Actual processing is done by a thread running at regular intervals.
However, this current architecture does not work when clients are firewalled or behind a NAT. In this case the server simply can not reach clients to push results to them.
Furthermore, in this current architecture the server does not know which client sent a given action, unless a redundant layer of authentication or session handling is introduced. This allows forged actions and cheating.
I've been thinking about possible solutions but haven't found a proper one:
Client pull instead of server push. There could be a method on the server that the clients call periodically to fetch their results. However, this approach seems very ugly, it introduces additional delays, bandwidth and timing issues. Does not solve action forgery either. Direct notifications are also very much preferred.
TCP connections by themselves allow bidirectional communication, and can definitely identify clients, so RMI or JRemoting might be hacked to support it, but I'm don't know how, and I'm not aware of any existing solution.
Message passing. I'm not sure whether message passing frameworks support authentication / sessions or client identification. I'd definitely lose remote methods though.
I believe the correct solution would be to find a remote method invocation framework that supports all of the above.
So in a nutshell, I'm searching for a way to:
call the server asynchronously or pass a message to it
call the client asynchronously or pass a message to it, even behind firewall or NAT
identify the client sending the action
preferably be able to call methods, not just pass messages
keep the ability to easily test it with JUnit and Mockito (multiple clients per machine)
Are there any remote method invocation frameworks with support for these? Which is the best?
I don't know why you would insist on using a RMI or anything similar, as it is by definition unidirectional. But I had to learn a similar lesson...for one of my client-server systems, I implemented something similar to what you have now, using RMI and long-polls. That turned out to be a horrible mess, that just getting worse and worse.
Then I found out about the wonderful world of publish-subscribe frameworks. These are a natural way to build a client-server application without the need to implement a lot of your own plumbing. Moreover, these frameworks support things like auto keepalives, time syncing, session authentication and permissions, and tons of other stuff that you wouldn't want to implement yourself.
For my project, I ripped out all of my own work and replaced it with CometD, which supports both Java and browser (Javascript) clients, and couldn't be happier. It would certainly support all your needs - asynchronous communication initiated from either side, client identification (and many other features), and clients behind NAT would not be a problem once a connection is established. Easy to write tests too, and the whole framework has been scaled up to be able to handle 100k clients, which would be impossible for RMI.
I would strongly suggest that you consider dropping the requirement to be able to call methods remotely. Methods are inherently one-sided, but they still require a call and return. It's much better to design your system with event-driven programming.
Update: I've since moved to the world of web apps, specifically using Meteor.
Any one dealing with the RMI would certainly have come across this dilemma of how to easily maintain the interfaces to objects providing remote method invocation service to other client applications. Whenever we decide to have a minor change in the method declaration or adding/deleting methods declared in the interface, we have to manually replicate the change in all the clients that would be using that interface for accessing RMI service from a remote server.
Think about having a downloadable (Serializable) agent that has a more stable interface used by the client, and that uses the remote interface to do its job. You can use the codebase feature to ensure its availability to all clients. The agent needs to contain the stub. You can bind the agent to the Registry, or return it from some other remote method.
Or, use JWS to distribute new versions of the clients.
Or, design your remote interfaces more stably so they don't have to change -:)
One of the good workaround I came up with is to
put all the interfaces provided by the RMI server in a separate
project which will pack itself into a jar file when built.
Then just add that jar file as dependency or in the
classpath of the server application which is meant to provide the
RMI service as well as to any of the client applications that
want to use those interfaces for invoking remote methods.
This will ease the task of maintaining RMI interfaces by updating them at just one place. Extra effort of changing method signature in some interface will be limited to changing the application code which calls that method.
Im trying to implement an Observer/Observable pattern on an EC2 instance. I have been able to create the application using RMI relatively simply. However trying to get RMI and the Amazon cloud to work has been neer impossible for client callbacks.
RMI also limits the client applications to being Java based. Hence i've been messing around with JAX-WS in order to use SOAP messages. However i havent been able to come up with a solid way to make callbacks on the client with it.
Does anyone know of a way that i would be able to program in a similar way that RMI works with client callback methods to update Observers when something on my server has been changed, using hopefully a language independent distributed method?
I would be willing to make it so that all my clients must be written in java, but i need to be able to get it working on the EC2 instance which RMI seems incapable of doing callbacks even if i open all TCP ports and use a security manager.
Thanks,
Ben
You could try a messaging solution, something like RabbitMQ.
In this way Observable pushes a message to subscribers (Observers). Completely decoupling your clients from the implementation language/specifics of the EC2 instance.
I'm experimenting with grails in order to interface with an online trading platform.
specifically Interactive Brokers (IB) http://interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
The way the API works is you need to have their client program, Trader Workstation (TWS http://interactivebrokers.com/en/p.php?f=tws&ib_entity=llc) running and then we consume the API to do stuff. Consuming the API basically involves creating a "broker" object, calling a connect() member function (this makes a local port connection to the TWS software) and calling something like getData()
The value of grails in this scenario are the GORM features and the web framework provided. I want to be able to define objects abstracted from db implementation, easily do persistance operations and easily provide users with a UI to do CRUD and custom actions.
My challenge is the IB API uses asynchronous communication for requests and replies. i.e. when i call getData(), the API knows to use the callback function dataResults() when it is ready to send them. In order for dataResults() to be callable, the broker object I created still needs to be around to receive the reply.
Inside a controller function, if i create a broker object and call getData(), when the request finishes, the broker object obviously also disappears. So I'll never be able to receive the reply.
I think there might be some way to do this by kicking off background threads but i'm not sure this is the path i want to go down.
Does anyone have any recommendations on what the best approach is?
I'm not married to grails, the reasons i'm using it are above. If there is a desktop app framework that I can also easily make a web interface on top of later, I'm definitely open to that.
thanks in advance.
Create your object in Service and make the Service singleton (which is by default):
static scope = "singleton"
In terms of web UI Grails is definitely a good choice.
Then, the asynchronous operations could be handled by Ajax calls as you shouldn't block the controller waiting for results.
The following [presentation][1] has some good examples
1: http://skillsmatter.com/podcast/java-jee/high-volume-scalable-ajax-with-grails
I have a problem with web services. They are programed in Java and are running on a WASCE server ( both are on the same server).
My problem that i want to solve:
We have two Web services: App1 and App2
In App1 i want to call a function that is in App2. How can i do this? Is this even possible?
I tried creating a soapClient inside the App1 so i can connect to the App2 but that doesn't work.
exp:
I have a client that calls app1 gets data from app1 and send it to app2 then get back the response data from app2 and send it to an other function into the app1.
What i want to do is to skip the client part and do it directly so that app1 can send directly the data to the app2 and then receive an answer do whatever it needs to do.
For the note: Both of the web services use the connection to the database.
Thank you in advance.
(it has been edited with additional data)
What does "doesn't work" mean? Exactly what happens?
Start by generating some client code for App2. Can you use that from some simple Java environment, or say a Servlet. If that works, what happens when you try to call it from inside your App 1 Service implementation code?
However: if these are related services running in the same JVM can you not set up some simpler relationship using java libraries. My preferred way of developing a service is first to develop some useful Java code, and make sure that works, then "wrap" it as a Web Service. In which case I have a callable routine that can just be invoked as Java.
It's definitely possible, with differing levels of complexity and feasibility depending on exactly what it is you want, and the restrictions you place on it.
Probably one of the simplest ways to go about this, if you don't have a problem with the method in App2 being public, is to simply create a web service exposing that method and call if from App1.
If you want App2's method to be essentially "protected", so that it can be called by App1 but not by public clients, then there are several alternative options. Firstly, you could use firewalls or equivalent to prevent external requests to the service URL. Alternatively, you could expose the method through some form of interprocess communication; RMI would be the obvious native one for Java (set up an RMI method in App2 and export this through a manager, then obtain the reference in App1 and invoke the method remotely). Depending on exactly what it is you want to do, you may be better off with a framework that does all this under the covers; e.g. distributed objects through something like Terracotta.
You should give more detail in your question, though - currently the only thing you've really specified is that you want to call "a function" in App2 from App1. There are dozens (if not hundreds) of ways to go about this and the best one(s) will depend on the details of what you're trying to do.
EDIT (in light of comments): It's not the details of what you want to do that are lacking - I understand fine that you want to call some method in App2 from within App1. It's more the architectural details - what languages are both clients coded in, what libraries are you using to do the web services, are both clients on the same machine or separate ones (and if same machine, same JVM or not), are there any firewall issues that could inhibit certain kinds of connectivity, are there any office-political restrictions that could inhibit your options, are there any security restrictions that could do the same (such as whether you can expose the functionality of App2's method publically or not). All of these will shape what is possible and what is optimal - because at the end of the day, all networking is basically I want to use resources on that remote computer from here. Without more architectural specifics, there are literally dozens of ways that you could achieve this.
Regarding exposition: You would create a web service to expose App2's function in the same way you would create any other web service (with the details being dependent on the tool/framework you're using). As an example if you're using a tool that supports the JSR-181 annotations, you'd write a method in App2 that performs this function, and annotate it with #WebMethod. Then you'd ensure that if this method is not part of an existing webservice class you'd annotate its class with #WebService. I was presuming that since you already have a couple of web services, you'd know how to write/define them.
As for accessing the web service from App1, this can be done quite simply by a Java SOAP client. A tool such as WSDL2Java can create a stub class modelling the remote service that you can call; alternatively you can get a richer interface with something like CXF.
What WS library are you using currently, and what errors have you encountered when trying to use it to perform this interaction?