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.
Related
I have an application implemented in JavaFX and it will be migrated to the web platform, but it will take some time for that.
Meanwhile, I am struggling with some problems regarding its uses. Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database.
My doubt is whether running the jar from the allowed network drive will solve this problem. In addition, can JNLP be a solution for this ?
I'd appreciate any help about this.
Some users need to launch the jar from a network drive because their machines do not have access to the the database. Only the drive where the jar is located has access to the database. My doubt is whether running the jar from the allowed network drive will solve this problem.
It won't work directly.
JavaFX is a client technology, it runs on a client PC. If the client PC does not have direct access to a database, then neither does a JavaFX application running on that client PC.
In addition, can JNLP be a solution for this ?
No, not for direct access to the database from the client if this isn't permitted in your network architecture, you would need a middle tier in addition to the JNLP based client to accomplish this.
Discussion of some solutions to this problem
Typically, the architecture of what you are describing would be built as a multi-tier app.
A client tier, which is the the JavaFX application or HTML javascript application running on a client machine.
An application server tier which handles server logic.
A database tier which hosts the DBMS.
There is a reasonable high level overview of such an architecture here.
Often, nowadays, the application server will serve REST APIs of JSON data, which a HTML based JavaScript web application can easily consume. Such APIs are also easily consumed using JavaFX applications which embed a REST client. An application server services the REST APIs and communicates with a database over JPA or JDBC as appropriate. However, than are many alternate technologies for client/server communication, and you can choose whatever you feel is a good fit for your application, development style and organization.
Spring product specific discussion
As you state your preference to use Spring, consider a JavaFX SpringBoot application.
Spring also includes a technology called spring remoting for facilitating client/server access. Spring remoting provides for multiple communication technologies. I'd advise sticking to the straight HTTP REST based technologies rather than other techniques such as RMI or AMQP as a HTTP REST based back-end can also serve as the backend for a standard HTML/JavaScript webapp which you also mention may be an eventual target client for your application.
If using Spring on client and server, checkout Spring's AsyncRestTemplate, and invoke JavaFX's Platform.runLater API inside the success and failure callbacks of the rest template. Or, use a Spring RestTemplate and control calls to the server via JavaFX concurrency mechanisms. Not sure which would be best for you, possibly the standard RestTemplate wrapped in a JavaFX Task.
Doing this in the correct manner will allow your application UI to remain responsive while it performs network activity (not block the UI thread) and also ensure that you don't violate JavaFX thread rules (don't access controls or modify data bound to JavaFX scene controls off of the JavaFX application thread).
My project is looking to deploy a new j2ee application to Amazon's cloud. ElasticBeanstalk supports Tomcat apps, which seems perfect. Are there any particular design considerations to keep in mind when writing said app that might differ from just a standalone tomcat on a server?
For example, I understand that the server is meant to scale automatically. Is this like a cluster? Our application framework tends to like to stick state in the HttpSession, is that a problem? Or when it says it scales automatically, does that just mean memory and CPU?
Automatic scaling on AWS is done via adding more servers, not adding more CPU/RAM. You can add more CPU/RAM manually, but it requires shutting down the server for a minute to make the change, and then configuring any software running on the server to take advantage of the added RAM, so that's not the way automatic scaling is done.
Elastic Beanstalk is basically a management interface for Amazon EC2 servers, Elastic Load Balancers and Auto Scaling Groups. It sets all that up for you and provides a convenient way of deploying new versions of your application easily. Elastic Beanstalk will create EC2 servers behind an Elastic Load Balancer and use an Auto Scaling configuration to add more servers as your application load increases. It handles adding the servers to the load balancer when they are ready to receive traffic, and removing them from the load balancer and deleting the extra servers when they are no longer needed.
For your Java application running on Tomcat you have a few options to handle horizontal scaling well. You can enable sticky sessions on the Load Balancer so that all requests from a specific user will go to the same server, thus keeping the HttpSession tied to the user. The main problem with this is that if a server is removed from the pool you may lose some HttpSessions and cause any users that were "stuck" to that server to be logged out of your application. The solution to this is to configure your Tomcat instances to store sessions in a shared location. There are Tomcat session store implementations out there that work with AWS services like ElastiCache (Redis) and DynamoDB. I would recommend using one of those, probably the Redis implementation if you aren't already familiar with DynamoDB.
Another consideration for moving a Java application to AWS is that you cannot use any tools or libraries that rely on multi-cast. You may not be using multi-cast for anything, but in my experience every Java app I've had to migrate to AWS relied on multi-cast for clustering and I had to modify it to use a different clustering method.
Also, for a successful migration to AWS I suggest you read up a bit on VPCs, private IP versus public IP, and Security Groups. A solid understanding of those topics is key to setting up your network so that your web servers can communicate with your DB and cache servers in a secure and performant manner.
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
I'm starting an JBoss to use on the development, and I'm using it as standalone.
I read that on the production environment the JBoss should be as a domain.
I searched for that to understand what's the difference between than. But I didn't found any document well explained.
That's not really correct. Standalone is fine for production. It's commonly used in production, especially when you only need one instance of the server.
Domain is used when you run several instances of JBoss AS and you want a single point where you can control configuration from. You can read more about it in the documentation.
Update
The link has been changed to the latest version of WildFly as the JBoss AS 7 documentation has been archived, but is still available at https://docs.jboss.org/author/display/AS71/Admin%20Guide.html#8094211_AdminGuide-StandaloneServer
Standalone mode
each JBoss server has its own configuration
single JVM process
Domain mode
central control of multiple servers
central configuration for multiple servers
It's important to understand that the choice between a managed domain and standalone servers is all about how your servers are managed, not what capabilities they have to service end user requests. This distinction is particularly important when it comes to high availability clusters.
So, given all that:
A single server installation gains nothing from running in a managed domain, so running a standalone server is a better choice.
For multi-server production environments, the choice of running a managed domain versus standalone servers comes down to whether the user wants to use the centralized management capabilities a managed domain provides.
Running a standalone server is better suited for most development scenarios. Any individual server configuration that can be achieved in a managed domain can also be achieved in a standalone server, so even if the application being developed will eventually run in production on a managed domain installation, much (probably most) development can be done using a standalone server.
For the Above explanation and more follow this link
Why do we need Application Server in Java like JBoss or WebSphere. Is it possible that we develop large scale website only with Java (Apache Tomcat). Where thousand of user connect on site at a moment. An example is a website like b2b.
What is the cost of a Application Server? I will be thankful if you compare price among different application server and if there is any free version kindly highlight it.
Application Servers are mostly used if you want to use advanced features like transaction management, hot code swapping and advanced persistence.
There are application servers that are open source. E.g. GlassFish and JBoss.
I don't think you need an application server for building a popular web site, you'll also be fine with a servlet container like Tomcat or Jetty.
In short Application Servers provide you with few services like
Transaction Management
Load Balancing
Security
Threading
etc.
You have to take care of these things yourself in a Web Server.
There are few Open Source Application servers which are free of cost.
I have used Glassfish.
Apart from answers given above, App Servers are required for EJBs.
You need Application Server as follow:
It provides you useful services like automatic transaction,Authentication,Authorization,Lifecycle management.
To remember large user data across pages using ejb's pertaining to a client.
Load balance the user request and buisness logic.
To interact with different Client UI like Java Swing,Browsers.
It is possible to handle the httpheaders yourself. We have done socket servers in java for 20 years. You do not need a container for java swing.
Persistence can be done through databases or server side files unless you need real high speed stuff. I have yet to find a real requirement for an ejb
except that some systems simply require them
This may be because jboss can provide better after-sales service, and jboss, etc. can provide operation and maintenance support, etc. This may be the reason why many large companies choose commercial versions of servers.
But you must know that tomcat and netty are not bad. For example, many large B2B or C2C or B2C companies still use tomcat, such as Internet companies such as Alibaba.
Choose a server
Operation and maintenance costs
Scalable costs
Server cost