I am looking to implement a Java RMI Server in our corporate network. This Java RMI Server will provide information to our Java Eclipse Client. I have everything working when I run the Java RMI Server on a machine with RMIRegistry and the appropriate Java call to run the program.
I am looking for some advice/suggestions on how I can make it more robust. Specifically the Java RMI Server will connect to a SQL Server DB. How can I deal with things like DB Connection Pooling? How do I scale up the number of instances of the Java Server program to all of my users?
I'm sure there are a lot of things to consider and I was hoping for some clarity on whether or not I need to download something like JBoss or is it overkill?
I don't believe I'll be able to run the RMIRegistry and Java server program by itself but I'm not sure what my next steps are.
Thanks,
Kevin
You do not need to use JBoss to provide RMI services if you don`t need an application server. You can run spring over tomcat or even implement web services to increase interoperability.
Unless you have a truly specific need to do RMI, I'd simply punt on RMI and implement a web service against any of the servlet containers. It'll likely just be easier, if for no other reason there are zillions of others doing the same thing, so there's lots of support for it.
If you still feel you want to use RMI, consider instead using JMX.
JMX make RMI much more painless. Every VM has a JMX service running in it "for free" and JMX is running RMI underneath.
JMX is also rather ubiquitous in the Java world, so there are lots of tools that can be used to interact with your servers (such as JConsole).
JMX is basically the RMI transport, with a much friendlier surface for management.
It's very difficult today to justify a greenfield RMI app, frankly.
Related
Background Context:
Due to enterprise limitations, an uncooperative 3rd party vendor, and a lack of internal tools, this approach has been deemed most desirable. I am fully aware that there are easier ways to do this, but that decision is a couple of pay grades away from my hands, and I'm not about to fund new development efforts out of my own pocket.
Problem:
We need to send an internal file to an external vendor. The team responsible for these types of files only transfers with SFTP, while our vendor only accepts files via REST API calls. The idea we came up with (considering the above constraints) was to use our OpenShift environment to host a "middle-man" SFTP server (running from a jar file) that will hit the vendor's API after our team sends it the file.
I have learned that if we want to get SFTP to work with OpenShift we need to set up of our cluster and pods with an ingress/external IP. This looks promising, but due to enterprise bureaucracy, I'm waiting for the OpenShift admins to make the required changes before I can see if this works, and I'm running out of time.
Questions:
Is this approach even possible with the technologies involved? Am I on the right track?
Are there other configuration options I should be using instead of what I explained above?
Are there any clever ways in which an SFTP client can send a file via HTTP request? So instead of running an embedded SFTP server, we could just set up a web service instead (this is what our infrastructure supports and prefers).
References:
https://docs.openshift.com/container-platform/4.5/networking/configuring_ingress_cluster_traffic/configuring-externalip.html
https://docs.openshift.com/container-platform/4.5/networking/configuring_ingress_cluster_traffic/configuring-ingress-cluster-traffic-service-external-ip.html#configuring-ingress-cluster-traffic-service-external-ip
That's totally possible, I have done it in the past as well with OpenShift 3.10. The approach to use externalIPs is the right way.
I am looking for a better logical solution of a situation where one core Java EE (Web) application will call/execute many other Java applications/workers (which can be core Java or J2EE(web) application (don't know what will be the best)) at a certain time.
Those other Java applications/workers will basically connect (individually) with different Data sources (can be from remote DB or REST or SOAP, etc...) and populate/update local DB at a certain period of time.
I was doing research on Java Quartz Scheduler recently. Do u have any good suggestion to me for this Enterprise level architecture?
Btw, I am using Spring 4, Java 7
Thank you as always for all good and professional ideas.
Sample diagram can be as follows:
You can connect your java application with others easy with spring's httpInvoker or rmiInvoker.
More information here: http://docs.spring.io/spring/docs/current/spring-framework-reference/html/remoting.html
Not sure to understand good, but you can look at a messaging mechanism. Typically, the WebApp will send a message that will be received by all the Workers.
Have a look a JMS which it designed for this kind of use, and integrates well with both JEE (it is a part of the JEE spec) and Spring.
There are basically two parts to your question:
How do I schedule jobs on a Java EE server?
How do I invoke remote services from that scheduled job?
Job Scheduling
The trick with job scheduling in a Java EE environment is that you are typically running jobs in a cluster, or more than one server. Thus, only one of the nodes should be running that job at a time "on behalf of" the cluster, otherwise, you'll get multiple calls to those remote resources for the same thing.
There is a standard out there for this, JSR-237, which covers Timers and WorkManagers. Each Java EE vendor has its own implementation. WebLogic has one, WebSphere has one, and JBoss has one (the JBoss one isn't compliant with the JSR, but it does the same thing).
If you are running one of the servers that only runs the web tier of the Java EE spec (i.e, Tomcat or Geronimo), then Quartz is a good choice.
How to invoke remote services from timed jobs
Echoing #Alexandre Cartapanis' answer, probably what you'll want to do is create a JMS Topic in your Java EE server, and then when the job runs, post a message to the topic. The remote services (whatever Java EE servers) subscribe to this topic, and then you can run your queries.
The big advantage here is that if you ever need to add another service that needs to populate the local DB, all you have to do is have that server subscribe to the topic - no code changes needed. With JSch or remoting, you'll have to make a code change every time a new service comes online. You also have to make code changes if DNS addresses or IP addresses change, etc, where as the JMS way is just configuration on the server. There's a lot more that you can do with JMS, and the support is much better across the board.
Spring has adapters for Quartz and I think there's one out there for WorkManagers and Timers too.
You can make use of JSch - Java Secure Channel to trigger remote ssh calls which can start a JVM and run the Worker class.
Here are some examples.
Anyone has expirience on having Jruby project running on Jboss (using torquebox or whatever) with an ability to communicate with another "japps" not on the same jboss where jruby app is, i.e. some java project on another jboss?
I know there is an torque-messanging but dunno if it's possible to communicate with external(out of jruby-app's jboss) app?
Best practices are welcomed.
Thanks in advance.
P.S. placing that other app on the jboss where jruby app is not acceptible solution.
I can recommend you to use Thrift and build communication via them.
Thrift have generator for both your needed languages (Java and JRuby) and provide good and fast communication.
UPDATED:
Thrift is RPC (remote procedure call) framework developed at Facebook. In detail you can read about it in Wiki.
In few word to save you time, what it is and how to use it:
You describe you data structures and service interface in .thrift file(files). And generate from this file all needed source files(with all need serialization) for one or few languages(what you need). Than you can simple create server and client in few lines
Using it inside client will be looks like you just use simple class.
With Thrift you can use what protocol and transport used.
In most cases uses Binary or Compact protocol via Blocked or Not-blocked transport. So network communication will be light and fast + with fast serialization.
SOAP(based on XML on HTTP) packages, its in few times bigger, and inappropriate for sending binary data, but not only this. Also XML-serialization is very slow. So with SOAP you receive big overhead. Also with soap you need to write (or use third-party) lib for calling server(tiny network layer), thrift already made it for you.
SMTP and basically JMS is inappropriate for realtime and question-answer communication.
I mean if you need just to put some message in queue and someone sometime give this message and process it — you can (and should) use JMS or any other MQ services(Thrift can do this to, but MQ architecture is better for this issue).
But if you need realtime query-answer calls, you should use RPC, as protocol it can be HTTP(REST, SOAP), binary(Thrift, ProtoBuf, JDBC, etc) or any other.
Thrift (and ProtoBuf) provide framework for generate client and server, so it incapsulate you from low level issues.
P.S:
I made some example in past https://github.com/imysak/using-thrift (communication via Thrift Java server + Java Client or node.js client), maybe it will be useful for someone . But you can found more simple and better examples.
Torquebox supports JMS. The gem you specified torquebox-messaging allows for publishing and processing of HornetQ messages on the local JBoss AS server/cluster that the JRuby app is running in. I don't think it currently supports connecting to remote servers.
Using this functionality in your JRuby app you could then configure your Java app on another server to communicate with HornetQ running in the JBoss AS that the JRuby app is running on.
Alternatively you could always implement your own communication protocol or use another Java library - you have access to anything Java you want to run from JRuby.
You can use Web Services or JMS for that
So my most basic question here is: how do you build TCP interfaces into your Java EE applications? Instead of interacting with a legacy EIS, I need to interact with a block of TCP/IP ports. Ideally, I'd like a message-driven bean to have it's onMessage method invoked by an incoming TCP request and also be able to respond back over the same connection.
JCA seems general enough to be capable of something like this within a Java EE environment. Would developing a custom connector be the appropriate technique for integrating inbound/outbound TCP interfaces in a Java enterprise ecosystem?
As far as what I've tried so far: we're currently utilizing a lifecycle module which starts by kicking off a number of TCP listeners; this invokes a message-driven bean which calls a business method, and it all returns over the same TCP stream. This is actually working alright, but the lifecycle support in my application server (Glassfish) feels like it has been added as an afterthought. So, JCA seems like a first-class solution to this sort of problem and it seems to enable us to communicate over TCP.
However, from the initial research we've conducted, it does seem like the connector architecture is 'targeted' towards legacy information systems, not generalized TCP communication. So, my question could be rendered: are people using custom JCA's to integrate TCP/IP into their Java EE applications -- or is there a better technique for accepting TCP connections from my EJBs?
MXBeans and JCA (MXBeans are easier, have implemented both) but basically you only need 2 things start/stop and possibly to rely on other MXBeans/JCA/JNDI to carry out your services w/ the AppServer generating the needed proxies for you.
Real application: hacked tomcat w/ the NIO acceptor that can trap connections on 80+443ports and still use the web-server normally.
Followed by full platform (incl. own (re)deployer) to manage sessions/messages and all the jazz.
It seems you already resolved your initial problem. It's nice, but to help people through, this is a nice sample on the matter: http://code.google.com/p/jca-sockets
I need to implement a SOAP Web service.
with many clients (over 4000 user online).
Service function is a DB access, and other web service access...
Which application server is better.
Glashfish, Weblogic, Oracle Application Server ...?
I'd suggest you first implement the Web service on an app server that you're experienced with (or a free one, like Glassfish or JBoss) and then stress test it. If you make it app. server agnostic, porting it to others, including the commercial ones, shouldn't be a problem.
It's usually best to just try out stuff like this for yourself because benchmarks won't always point you to the right direction.